Resume Formatting Myths, Measured

The advice and the measurement

Search for resume formatting guidance and you will find a confident list: avoid columns, avoid tables, avoid headers and footers, avoid tight spacing, avoid fancy bullets, avoid graphics. The list is treated as settled knowledge. It is almost never accompanied by a measurement.

We ran one. The study uses a controlled corpus of synthetic resume PDFs, generated with pdf-lib and read back with PDF.js. Each condition changes exactly one formatting property against a single-column control. The intended text is known exactly, so every difference in the output is attributable to the property under test.

What came out is a ranking that looks different from the usual advice. The most damaging condition is barely discussed. Several commonly warned-about conditions did nothing. And the damage that does occur is not where most people expect it.

What follows is a condition-by-condition walkthrough, organised from the most damaging to the least, with the measurements behind each claim.

Priority one: a missing text layer loses everything

The scanned-image condition returned 0% of its words, 0% of its email addresses and 0% block integrity. Every metric was zero. The document produced no text items at all.

This is the only condition in the study that destroys a resume outright. Every other condition, including the ones that cause real damage, returned at least 96.9% of its text. The gap is not gradual. It is the difference between a document that is damaged and one that does not exist.

A scanned page happens when a resume is printed and re-scanned, photographed, or exported through a flatten-to-image option. The result looks normal on screen but contains no text layer. The select-all test catches it in seconds.

Priority two: side-by-side layout welds unrelated content

Two-column resumes returned 97.9% of their words, which sounds adequate. But 30.5% of output lines were fused from two unrelated parts of the page. A phone number lands in the middle of a bullet about Kubernetes. A section heading welds to an achievement from a different section.

Narrowing the gutter made it worse: the narrow-gutter condition welded 33.1% of lines. Table grids welded 24.1%, less severe and more often within related content, but still non-zero.

The mechanism is consistent. A reader groups text by vertical position, sweeping horizontally across the page. When two unrelated fragments sit at the same vertical coordinate, they become one line. This is the only structural damage in the study, and it is specific to content placed side by side.

Priority three: letter-spaced headings shred words

Both letter-spacing conditions returned 96.9% of words, the lowest recovery of any condition with a text layer. The loss was concentrated entirely in the section headings, which came back as individual characters separated by spaces: "E X P E R I E N C E" instead of "EXPERIENCE".

This matters more than the small percentage suggests. Section headings are exactly what software uses to segment a resume into experience, skills and education. Losing the word EXPERIENCE does not lose one word. It loses the boundary that organises everything below it.

The mechanism is precise. A reader decides whether two fragments are one word by measuring the horizontal gap against a threshold scaled to character height. Normal glyph spacing falls under the threshold. Letter-spacing pushes every gap above it, so each character becomes its own word.

Priority four: margin contact details relocate

Contact details placed in the page header or footer scored 100% word recovery and 93.7% reading-order fidelity. The words survived but they moved. The email and phone number ended up at the far end of the extracted text, a long way from the name they belong to.

This is not a catastrophe. The contact information is present and intact. But if downstream software is looking for a phone number near a name, or expects contact details at the start of the text, the distance is not free. It is a quiet displacement that may or may not matter depending on how the receiving system parses the output.

The fix is straightforward: put contact details in the body of the page rather than in the margins. That keeps them near your name in the extracted text regardless of how the reader traverses the page.

Everything else we tested did nothing

Four conditions scored identically to the single-column control on every axis we measured. No word loss, no order disruption, no line welding.

Tight leading, set at two points, scored 100% recovery, 100% order, 0% welded. The reader's 2.5-point grouping tolerance was never crossed because font size plus leading still exceeds the threshold, even at extreme settings.

Decorative bullets drawn from ZapfDingbats scored 100% on every axis. PDF.js resolved the font encoding correctly and the symbol-mapped characters did not contaminate the surrounding text.

Rotated sidebars scored 100% recovery and 100% order. The body text was untouched and the rotated content was recovered, though at the end of the document rather than in its visual position.

Documents with no space characters at all, where every word boundary was a coordinate gap rather than a character, scored 99.8% recovery and 99.8% order. The reader reconstructed word boundaries from geometry almost perfectly.

The full comparison

All 12 conditions, scored on word recovery, reading-order fidelity and line welding. The table is sorted from the most damaging to the least. Where a condition matches the control exactly, it changed nothing measurable.

Three metrics tell most of the story. Recovery measures whether the words came back. Order measures whether they came back in sequence. Welding measures whether unrelated content was fused into single lines. A condition can score well on recovery and still fail on order, which is why recovery alone is misleading.

What this does not settle

Null results are not proof of safety in general. They are one measurement with one reader. PDF.js is one extractor among many, and employer systems may use others with different tolerances, different grouping logic, or different failure modes. A condition that did nothing here could matter elsewhere.

Some advice exists for human readers rather than for parsers, and that is a legitimate reason to follow it even when extraction is unaffected. Tight spacing makes a resume harder to skim. Unusual bullets may distract or confuse. Rotated text is unconventional. These are real concerns, but they are design concerns, not parsing concerns, and conflating the two makes the advice less useful.

The study also tests only formatting. It says nothing about content quality, keyword relevance, or how any company scores or ranks applicants. Passing extraction is the floor, not the ceiling. A perfectly parsed resume with weak content is still a weak resume.

Finally, we tested one aggressive setting per condition. Tight spacing at two points does not prove that all tight spacing is safe. Decorative bullets from one font do not prove that all symbol fonts are safe. Generalising from a single test point requires caution, and we state that caution here explicitly.

A shorter, measured checklist

If the study reorders the usual advice, the result is a shorter list ranked by measured damage rather than by repetition frequency.

• Check for a text layer. The scanned page is the only condition that loses everything, and the select-all test catches it in seconds.
• Avoid placing unrelated content side by side. Two-column layouts welded 30.5% of lines. This is the most common structural damage in the study.
• Do not letter-space section headings. They returned only 96.9% of words, and the lost words are the ones that define the document's structure.
• Keep contact details in the body rather than the page margins, so they stay near your name in the extracted text.
• Choose line spacing, bullet style and font for readability. We could not measure extraction damage from any of them, and the reason to care about them is the human reader.