Two-column resumes and ATS parsing: what actually breaks

Ask whether two-column resumes are ATS-safe and you will get two confident, opposite answers. Both camps are right, because the answer does not depend on your resume. It depends on which text extractor sits behind the application form, and there are three common ones that disagree with each other by design.

A PDF has no reading order

This is the part almost every guide skips, and it explains everything else.

A PDF does not store paragraphs, columns, or a sequence. It stores instructions to draw glyphs at coordinates. When software needs the text back, it has to reconstruct an order that was never recorded. Apache PDFBox, the library underneath a great deal of enterprise document processing, states the problem plainly in its own documentation: "The order of the text tokens in a PDF file may not be in the same as they appear visually on the screen. For example, a PDF writer may write out all text by font, so all bold or larger text, then make a second pass and write out the normal text."

The W3C describes the same failure in its accessibility guidance, and its example is exactly a resume sidebar: "some documents use multiple columns, and the reading order is clear visually to sighted users as flowing from the top to the bottom of the first column, then to the top of the next column. But if the document is not properly tagged, a screen reader may read the document from top to bottom, across both columns, interpreting them as one column."

Swap "screen reader" for "resume parser" and you have the entire two-column problem.

Three strategies, three different answers

Every extractor picks a strategy for rebuilding that missing order. The three you are most likely to meet behave differently on the identical file.

Content stream order returns text in the sequence the PDF draws it, which for a document exported from a web page or a word processor is usually the underlying document order. Apache PDFBox does this by default: its documentation notes that "by default PDFBox does not sort the text tokens before processing them due to performance reasons." A sidebar authored before the main column comes out as one clean block, followed by the main column.

Position sorting rebuilds the order from coordinates, top to bottom and left to right. Anything sharing a horizontal line merges into that line. The Python library pdfplumber works this way, and describes its alternative mode as using "the PDF's underlying flow of characters as a guide for ordering and segmenting the words, rather than presorting the characters by x/y position." Presorting is the default. This is the strategy that shreds a sidebar.

Column detection tries to identify the columns and undo them. Poppler's pdftotext, the command-line tool behind many pipelines, takes this route: its manual says the default is to "'undo' physical layout (columns, hyphenation, etc.) and output the text in reading order." When the detection works, a two-column resume reads correctly. When it misfires, you get a hybrid of the other two outcomes.

So the honest answer to "is a two-column resume ATS-safe" is that it is safe under the first and third strategies and unsafe under the second, and you never find out which one you drew.

What this looks like on a real resume

We ran our own template library through a position-sorting extractor, the pessimistic case, to see how each layout survives. The results were not subtle.

Our full-height sidebar templates, the ones with a coloured column running the height of the page, came apart. Here is the top of one of them as the parser read it:

Experience
Senior Machine Learning
Mar       — Present
Engineer (LLM & Retrieval
Lead)
Dalad Nosson

The candidate's name lands in the middle of a job title. Every word is present and nothing is missing, which is precisely why this failure is so easy to miss: a human proofreading the PDF sees a clean document. A recruiter searching that database for a job title finds a fragment.

The same file, read by the same library with content-stream ordering switched on, comes out perfectly ordered: name, headline, contact details, summary, then the main column. The file was never broken. The reader was.

How common is this, really

An October 2025 paper from a team studying large-scale resume extraction puts a number on the exposure: "approximately 20% of resumes employ non-linear, multi-column layouts that break the standard top-to-bottom, left-to-right reading flow." Reconstructing reading order from those layouts is treated as a distinct engineering problem, separate from reading the text itself.

That is a useful frame. Roughly one resume in five is carrying a risk its author cannot see, and the systems on the other side are actively building machinery to compensate for it. Some of that machinery works. You have no way to know whether the employer you are applying to has it.

The rule that gets you columns anyway

The useful distinction is not one column versus two. It is whether anything sits beside your work history.

A full-height sidebar shares a horizontal line with every entry in your main column, so position sorting interleaves the whole document. That is the arrangement that fails.

A band is different. A band is a section that owns its full width and happens to lay its own items out in columns, with nothing beside it. Your skills list in two or three columns is a band. So are languages and interests. A position-sorting parser merges the items within one row of that band, and nothing else, because there is no other content at that height to merge with.

When we rebuilt a template on that principle, it scored full marks on the same check that our sidebar layouts failed. Three details did the work:

1. Bands hold short, single-line items only. We first tried a two-column education section and watched the next section's heading fall into the gap between two entries of unequal height. Multi-line entries belong at full width.
2. Use a grid that flows across rows, not newspaper columns. CSS multi-column flows down column one, then down column two, so a visual row is items 1, 13, and 25. A grid flows left to right, so a visual row is items 1, 2, and 3, and reading across it reads them in order.
3. Put a visible separator between the cells. This one mattered more than we expected. Without it, a merged row reads as Prompt engineering Cross-functional collaboration, two phrases run together. With a middot in each cell, the same row reads as Prompt engineering · Inference optimization · Retrieval systems ·, which is a correctly delimited list. That single change moved our banded template from a passing score to a perfect one.

You keep the density and the visual structure of a two-column resume. You give up only the full-height sidebar, which is the one element that cannot be made safe.

One more trap worth knowing

While testing, we found a font setting that silently deleted every year from a resume's text layer. The dates rendered correctly on screen and in print, but the extracted text read Mar Present. The cause was a typographic feature that swaps in alternate digit glyphs, which the PDF export then wrote without a mapping back to real characters.

There was no visual symptom at all. The only way to catch it was to extract the text and look.

The general lesson matters more than the specific bug: what a PDF displays and what a PDF yields as text are two different things, produced by two different mechanisms. Styling choices can quietly break the second without touching the first. This is also why the copy-and-paste test is worth doing on every resume you build, whoever built it.

What to do

If you are deciding on a layout right now:

• Default to a single column for the parts that carry your history. Work experience, education, and projects should never have anything beside them.
• Use bands for short lists. Skills, languages, tools, and interests can sit in two or three columns safely, with a visible separator between items.
• Keep dates on the same line as the role they belong to. A right-aligned date column is a second column, and it extracts as a detached block of bare years.
• Use standard section headings. This is the cheapest reliability you can buy, and it is covered further in our guide to ATS optimisation.
• Test by extracting, not by looking. Select all, paste into plain text, and read what comes out.

A two-column resume is not disqualifying, and anyone who tells you it is has skipped the part where three different parsers give three different answers. But a sidebar is a bet on which library the employer runs, placed without knowing the odds. Bands give you most of the design for none of the wager.

---

ResumeCommand's templates are built and checked against this failure mode, and you can run the same readability analysis on any template before you download it, so you see what a parser sees rather than guessing.

Try it free → ResumeCommand

Sources

• Apache PDFBox, PDFTextStripper API documentation (text token ordering and the setSortByPosition default): pdfbox.apache.org
• pdfplumber, extract_text and the use_text_flow parameter: github.com/jsvine/pdfplumber
• Poppler, pdftotext manual (default reading order, -layout and -raw): mankier.com
• W3C, Technique PDF3: Ensuring correct tab and reading order in PDF documents, Techniques for WCAG 2.0: w3.org
• Zhu et al., Layout-Aware Parsing Meets Efficient LLMs: A Unified, Scalable Framework for Resume Information Extraction and Evaluation (October 2025): arxiv.org

Back to resources