Guide
Why two-column resumes get scrambled, and the number that decides it
A parser sees no columns — only fragments with positions on a page. Whether your two columns survive comes down to whether the gutter between them is wider than a wide space, which is a measurement you control and nobody tells you about.
Last updated
Why do the published answers disagree?
Because they are testing the wrong variable. You can find a test reporting two-column resumes parsing marginally better than single-column, and another finding a two-column layout the only one of six to draw a critical flag. Both can be honest results.
The outcome does not depend much on which applicant tracking system receives the file. It depends on the document — on how wide the gutter is, what size the body text is set in, and whether anything spans the full width. Two resumes, both “two-column”, can land on opposite sides of the threshold. So a test of one specimen against one system tells you about that specimen.
We know the thresholds because Haisleaf imports resumes from PDF, which means we had to pick them. What follows is our reader. The numbers are ours; the decision — infer the columns from coordinates, because the file does not say — is forced on anything reading a PDF.
Both columns land on the same line
The first step in reading a page is grouping fragments into lines, and lines are found by vertical position: two fragments belong to the same line if their baselines sit within about half an em of each other. A fixed pixel tolerance would merge lines in a 9pt block and split them inside a 24pt heading, so it has to scale with the type.
Which means the first line of your job history and the first skill in your sidebar — level with each other on the page, in different columns — are the same line as far as this stage is concerned. That is not a bug. It is what “level with each other” means when all you have is coordinates.
The number that decides it
Having grouped a row, the reader sorts it left to right and walks the gaps. Every gap is either a space inside running text or a boundary between two layout regions, and the width is the only evidence available:
| Gap | What it usually is | What the reader does |
|---|---|---|
| ~0.25em | An ordinary word space | Joined, with a space |
| ~0.5em | A wide space in justified text | Joined, with a space |
| Under 2.5em | A tab, an indent, a narrow gutter | Still joined — the boundary is lost |
| Over 2.5em | A generous gutter | Split — the columns survive |
Two and a half ems is the line we drew, and the reasoning is that nothing in running text gets near it. An ordinary word space is about a quarter of an em. A wide space in justified type rarely passes half. So a gap of two and a half ems is not a space that got stretched — it is a deliberate separation, and treating it as a boundary is safe.
In practice: at 11pt body text, two and a half ems is roughly 27 points — about 0.38 inch, or 10mm. A gutter narrower than that is ambiguous. That is the number nobody tells you, and it is the one thing about a two-column resume you can actually check with a ruler.
Why getting it wrong is permanent
When the gutter is too narrow, the two fragments are joined into a single string: Software Engineer React. Read that back and ask where the column boundary was. There is no answer — not because the information is hard to recover, but because it is gone. The boundary was never in the text. It was only ever in the gap, and the gap was consumed when the strings were joined.
This is why a parse can fail silently and completely. Nothing errors. The words are all present and every one is spelled correctly. They are simply in an order nobody can use, and a keyword search over them still matches, so even a scoring tool may report your resume as fine.
Splitting at the gap is what preserves the alternative. Each fragment keeps its own position, so a later stage can group fragments by which x-range they fall in and recover the columns properly. That option exists only if the split happened first.
The failure underneath the famous one
Suppose the gutter is wide and the columns are cleanly separated. There is a second, quieter problem that survives.
After lines are found, they have to be reassembled into paragraphs — because a wrapped line and a new paragraph look identical in a PDF. The test is the one a typesetter would use: a line that wrapped ran all the way to the right margin, and a line that ended a paragraph stopped short. So the reader compares each line’s right edge against the rightmost edge on the page.
On a two-column page, the rightmost edge belongs to the right column. A line in the left column that fills its own column perfectly still ends far short of it — by the whole gutter plus the width of the other column. So no line in the left column ever looks like it wrapped, and every one of them becomes its own paragraph.
Your three-line role description arrives as three separate paragraphs. The words survive, the sentences survive, and the structure quietly does not. This one is invisible to a keyword check, which is why it is not in any of the tests.
What to actually do
- If a machine is reading it, send one column. Not because two are forbidden, but because one column has no gutter to measure and therefore no guess to get wrong. It is the only version that cannot fail this way.
- If you keep two, make the gutter obvious. Wider than 2.5× your body text size — around 10mm at 11pt. Design instinct says tighten it; the parser needs the opposite.
- Keep experience in the main flow. Put the sidebar to work on things that survive being read out of order: skills, tools, languages. A bulleted achievement belongs in the wide column.
- Do not build the columns out of a table. Cell order and visual order are different things, and that shuffles the text on a second axis before any of the above applies.
- Read it back. Select all, paste into a plain-text editor, and read top to bottom. If a skill appears in the middle of a job, the gutter lost.
Haisleaf exports plain text alongside every PDF, from the same document, so step five is one click rather than a copy-paste. The wider picture of what a parser keeps and what it drops is in what an applicant tracking system actually reads, and the emphasis half of it in does an ATS read bold text.