Tight Line Spacing Did Not Break Extraction

What the advice says

Resume formatting guides routinely warn that tight line spacing can cause an ATS to merge lines, skip text, or misread section boundaries. The advice sounds mechanical and plausible: if lines are too close together, the parser cannot tell where one ends and the next begins.

The problem is that the claim is almost never sourced. It is repeated from guide to guide without a measurement behind it, and the mechanism it describes is specific enough to test. So we tested it.

We set leading to two points, which is far tighter than any sensible resume design. Normal body text in a resume uses something between ten and fourteen points of leading. Two points produces a wall of overlapping descenders and ascenders. If tight spacing were going to break line grouping, this would break it.

What the extraction test showed

The tight-leading condition scored 100% word recovery across all 9 resumes. The single-column control also scored 100%. Reading-order fidelity was 100% against 100%. Line welding was 0% against 0%.

Every metric we measured was identical. Not close, not approximately the same, but exactly the same to the precision we scored. The tight-leading condition and the control produced the same output.

This is a clean null result. In a study where two-column layouts welded 30.5% of lines and letter-spaced headings lost 96.9% of words, the tight-spacing condition changed nothing.

Why it did not break

The mechanism is worth understanding, because it explains both why this passed and under what conditions it might not. PDF text extraction works in two phases. First the reader collects every positioned text fragment on the page. Then it groups fragments into lines based on their vertical coordinates.

The grouping rule our reader uses is a vertical tolerance of 2.5 points. Two fragments belong to the same line if their baselines are within 2.5 points of each other. Two-point leading places successive baselines further apart than 2.5 points, because the font size itself contributes to the distance between baselines. Leading is the extra space added beyond the font body, not the total distance.

A twelve-point font with two-point leading places baselines fourteen points apart. A ten-point font with two-point leading places them twelve points apart. In both cases the gap is well above the 2.5-point threshold where line grouping would fail.

This means the tolerance would only be crossed if the font size were extremely small, or if leading were set to a negative value that pulled baselines closer than the font body itself. We did not test negative leading, and we cannot rule it out. But in the aggressive positive case we did test, the mechanism held comfortably.

What this does not prove

A null result is not a safety certificate. It is one measurement under one set of conditions. We tested one aggressive leading value with one reader and one set of font sizes. Other things we did not test could change the outcome.

Negative leading, where baselines are pulled closer than the font body, was not tested. Extremely small font sizes combined with tight leading were not tested. Other PDF readers with different grouping tolerances were not tested. It is entirely possible that some combination of small font, extreme spacing, and a different reader would produce line merging.

We also tested only one reader: PDF.js. Employer systems use a range of extractors, and their line-grouping tolerances may differ. A reader with a wider tolerance could be more sensitive to tight spacing. We measured what one reader does under one condition, and the answer was nothing.

So the accurate summary is: two-point leading did not break extraction in this test. It is not proof that tight spacing is always safe. It is evidence that the mechanism people worry about did not activate under the conditions we measured.

The real reason to keep line spacing

If tight spacing does not break the parser, why does every guide warn against it? Part of the answer is repetition without measurement. But part of it is a real concern that has nothing to do with extraction.

A recruiter does not extract your resume. They read it. They skim it, usually in under thirty seconds, looking for signal: relevant job titles, recognisable companies, clear achievements, a logical career progression. Spacing, alignment, and visual hierarchy are what make that skim possible.

A resume set in two-point leading is physically difficult to read. Descenders from one line overlap ascenders from the next. Sections blur together. The eye loses its place. None of this registers in an extraction test, because the parser does not use visual hierarchy. It reads positioned fragments and measures coordinates. What looks like a wall of text to a human is, to the parser, a perfectly orderly sequence of baselines.

That gap between the human view and the machine view is the most important thing in this post. The advice to use sensible line spacing is correct. The reason given for it is usually wrong. It is not about the parser. It is about the person.

What to do with this information

If you are choosing line spacing for a resume, choose it for readability. Ten to fourteen points of leading for body text is conventional, comfortable, and gives a recruiter space to skim. There is no extraction reason to go tighter, and there is a strong human reason not to.

If you are reviewing a resume that someone else wrote in tight spacing, do not assume the ATS will reject it. The parsing risk, at least under the conditions we measured, is not there. The readability cost is real but it is a design problem, not a technical one.

If you are building or advising on resume-checking tools, do not flag tight spacing as a parsing failure. Flag it as a readability concern if you want, but be honest about the mechanism. Telling someone their resume will not parse because of line spacing, when the evidence says it will, erodes trust in the tool.

Other null results in the study

Tight leading was not the only condition that changed nothing. Decorative bullets drawn from a symbol font scored 100% recovery and 100% order. Rotated sidebars scored 100% on every axis. Documents with no space characters at all scored 99.8% recovery and 99.8% order.

The conditions that did cause measurable damage were specific: side-by-side layout welded roughly a third of lines, letter-spaced headings shredded the words they were applied to, and the scanned page lost everything. The full comparison is published in the companion study post.

The pattern is consistent. The things most commonly warned about are not the things that cause the most damage. The things that cause the most damage are either catastrophic (missing text layer) or structural (content placed side by side). Spacing, bullets, and font tricks were, in our measurements, noise.