Does an ATS read tables and two-column resumes? We tested it

How we tested it

Most advice on this question is opinion. We could measure it because of how CVLoom is built: a resume's content is stored separately from its design, so the same words can be poured through different geometries. That gives a controlled experiment — identical text, only the layout changes, so any difference in what a parser extracts is caused by the layout alone.

For each layout we exported a real PDF through our production pipeline, extracted its text layer, and measured two things. Order fidelity is the share of the resume's content that still appeared in its intended sequence after extraction. Glued lines counts places where text from two different columns arrived fused into a single line.

What we found

One resume, five layouts, identical words. First measured 11 August 2026; re-measured 14 August 2026 after we rebuilt our column reconstruction — the grey numbers are the original engine.

The finding that surprised us

On the original run, the Sidebar layout scored 94 out of 100 on our own 30-rule checker — comfortably interview-ready — while keeping only 43%of its reading order. Its summary field came back holding 939 characters when the actual summary was about 200: sidebar content had been swallowed into it wholesale.

That is worth sitting with, because it means a good ATS score does not prove your resume reads in the right order. They are two different axes. A score measures whether the ingredients are present and well written; reading order measures whether they arrive in a sequence that still makes sense. A layout can pass the first and quietly fail the second — which is exactly why our checker warns about multi-column layouts even when everything else looks fine.

The failure mode is always the same shape. A parser walks the page top to bottom; when two columns sit side by side, it alternates between them. A line of your job description is followed by a line of your skills list, then back again. Nothing is lost, but the boundaries between sections dissolve — and section boundaries are how a parser decides what your job title was, when you worked there, and which skills to index.

What we fixed, and what it proves

After publishing the first run we rebuilt our extraction engine's column handling: it now finds the empty vertical corridor between columns, splits lines that were fused across it (text printed at the same height in both columns), and emits each column as one contiguous stream. On the re-run, every glued line disappeared — five to zero across the layouts — and the Sidebar summary came back at exactly its intended length instead of absorbing 939 stray characters. Sequence preservation rose on every two-column layout.

Two honest footnotes. Sidebar's 60% is no longer scrambling — the parser reads the sidebar column in full before the main column, so the “lost” sequence is a deliberate column order, with every section intact. And SWE Two Column still under-detects sections despite 89% order fidelity — its remaining problem is heading styling, not reading order. We publish that instead of hiding it for the same reason this page exists.

The lesson for your own resume is unchanged: you cannot fix a parser you don't control. We could repair our engine because we own it — the ATS at the other end of a job portal is not yours to repair, and the safest input to it is still a single column.

So should you use tables or columns?

• 1.Applying through a portal? Use a single column. Both single-column layouts in our test came through with zero glued lines and every section correctly identified. It is the only shape with no downside at the parsing stage.
• 2.Never use a table for page layout. Tables used to position blocks — a skills box beside an experience box — are the two-column problem with extra steps. A table holding genuinely tabular data inside one column is far safer.
• 3.Emailing a human, or applying somewhere small? Use whatever design you like. Most of the internet's panic about this assumes every application goes through an enterprise ATS. Many don't.
• 4.Test yours in ten seconds. Open your PDF, select all, copy, paste into a plain text editor. That is approximately what a parser sees. If sentences from two columns are spliced together, you have found the problem.

The practical move is to keep both: a single-column version for portals and a designed one for humans. In CVLoom that costs nothing — your content is stored separately from the design, so switching between a single-column layout and a two-column one re-flows the same words instead of making you retype them.

Where this sits in the rule set

Reading order is Rule 2 of the 30 rules CVLoom checks, and it sits in the Parseability category — the heaviest of the four, worth 40 of the 100 points, because a document that extracts wrongly cannot be rescued by good writing further down. The full rule set is published here, with the reason parsers break on each one and how to fix it.

Common questions