Short answer: a two-column layout is a parsing risk, not a documented rejection trigger. Greenhouse lists columned layouts among its unsuccessful-parse causes, and parser vendor RChilli documents reading-order problems with parallel content — but no vendor we found says a multi-column resume is automatically rejected. At the document-reading stage the software is extracting text, not grading your layout choices. Single column is still the safest default because it removes the risk class entirely. The full format checklist is in our ATS-friendly format guide.
What the vendors document
Greenhouse's help centre lists "Resumes that have a columned layout" and "Complex resumes with tables" among the causes of an unsuccessful resume parse (Greenhouse). As with headers and footers — a related documented risk we cover separately — this is a page about when parsing fails, not about applications being rejected.
RChilli, a vendor that sells parsing engines to ATS products, documents the mechanism from the parser's side: it reads "the content from the left-hand side first", which can separate a job title from its employer, and it lists "Data in tables/in parallel format" as a problem area in the employment section (RChilli). Note the shape of that warning: it is not "columns are forbidden" — it is "parallel data can come apart in the wrong order". That distinction is exactly why a two-column resume sometimes parses fine and sometimes does not: what matters is whether each column's content still stands alone when it is read out of sequence.
Reading order is the real issue
Roche's employer-side parsing FAQ describes the failure mode in one line: some systems "will read columns straight across rather than reading column one top to bottom" (Roche careers). Straight-across reading is what scrambles a two-column resume: a left-column job title gets glued to whichever right-column bullet happens to sit beside it, dates drift onto the wrong role, and the extracted text reads like a shuffled deck. A human never sees any of this — they see the layout; the parser sees the sequence.
A concrete example makes the failure visible. Picture a common designer template: a left sidebar holding your name, contact details and a skills list, the right column holding your jobs. Read straight across, line by line, the extraction starts pairing whatever sits at the same height — your name next to a job title, three sidebar skills spliced into the middle of a bullet about a different role, a certification sandwiched between two employers. Nothing is deleted; everything is missequenced. That is why a two-column resume can look immaculate to you and arrive as word salad in the recruiter's search index: the reading order broke, not the content.
Career centres disagree with each other
This is one of the few ATS topics where adviser guidance genuinely splits. George Mason University's career office says "Use a simple, single-column layout (no tables, text boxes, charts)" (GMU). UC Irvine's 2025 career guide gives the opposite shape of advice: "Use one or two columns to prevent parsing errors" (UC Irvine). Neither is vendor documentation — both are career-centre guidance — and the honest summary is that advisers disagree on whether two columns are acceptable, while the only vendor sources on the topic describe them as a risk.
The Lever misattribution
You will also meet the claim, repeated across resume blogs, that Lever's documentation gives tables and multi-column layouts the all-clear. When we read Lever's current help article on the subject (October 2026), tables and columns are not mentioned at all (Lever). Blogs attributing an endorsement to a vendor page that doesn't discuss the topic is textbook misattribution: the page is real, the endorsement isn't on it.
Parsing risk is not automatic rejection
Notice what every source above actually claims: columns can break parsing — extract text out of order, detach dates from roles, drop a sidebar's skills — not that a two-column resume gets rejected. This parse-versus-reject distinction runs through all ATS folklore; we traced the biggest example in do ATS really reject 75% of resumes? The practical consequence of a scrambled parse is that the recruiter's search for "Kubernetes" or "CPA" misses the qualifications sitting in your second column. You lose retrievability, not the application — though a resume whose keywords can't be found is effectively invisible, which is bad enough.
| Claim | What the source says | Source type |
|---|---|---|
| Columned layouts are a parse risk | "Resumes that have a columned layout" — Greenhouse's list of unsuccessful-parse causes | Official (ATS vendor) |
| Parallel content separates from its context | RChilli reads "the content from the left-hand side first"; "Data in tables/in parallel format" is a listed problem | Official (parser vendor) |
| Columns can be read straight across | "will read columns straight across rather than reading column one top to bottom" (Roche) | Practitioner (employer FAQ) |
| Use one column only | "Use a simple, single-column layout (no tables, text boxes, charts)" (GMU) | Practitioner (career centre) |
| One or two columns are fine | "Use one or two columns to prevent parsing errors" (UC Irvine career guide) | Practitioner (career centre) |
| Lever's docs endorse multi-column | The current Lever help article does not mention tables or columns — misattribution | Myth (misattribution) |
What to do
- Default to a single column — it removes the reading-order risk class entirely and gives up nothing a parser cares about
- If you must keep a two-column look, put nothing the ATS needs in the second column: contact details, job titles, employers and dates all live in the main flow (the header-placement rules apply to sidebars too)
- Avoid layout tables: RChilli's parallel-format warning is specifically about employment data, and tables are on Greenhouse's parse-causes list as well
- Keep skill keywords as real text in the main column, never as graphic skill bars — Greenhouse lists graphics among its parse-failure causes
- After export, copy-paste to plain text and read the order top to bottom — if it reads sensibly, a linear reader will too
If you are choosing a template, judge it by the extracted text rather than the preview: export, copy, paste, read. A template that looks designed and still extracts linearly is fine; one that extracts as a scramble is costing you retrievability no matter how good it looks. The same test settles the single-column question for your specific file — which is worth doing, because the sources above tell you what can go wrong with columns in general, and the paste tells you what actually went wrong in your case. Thirty seconds with a text editor beats any amount of template marketing copy.
How to check your own resume
Run the exported file through the free resume checker and look at what gets extracted: your skills, titles and dates should all appear, in a sane order. Then paste the target job description into the matcher to see which of its keywords the extracted text actually contains — a two-column resume whose second-column skills never make it into the extraction shows the gap right there. For a comparison of genuinely free checking tools, see free resume checkers.