Do Tables and Columns Break ATS Parsing?

Two of the most repeated warnings in resume advice are "never use tables" and "never use columns." They get treated as the same rule, and they aren't. One describes a real and common failure; the other is largely a holdover from software that has mostly been replaced. Knowing which is which decides whether you have to rebuild your resume or can leave it alone. The mechanics behind both are in our explainer on how an ATS reads a resume, the element-level version for graphics and icons is in our breakdown of graphics and icons, and if you want to test your own file rather than reason about it, our five-minute parsing check settles it in about the time it takes to read this. Every layout in our ATS-safe collection is single-column precisely because of what follows, and the full ATS collection covers the rest.

The one thing that decides it

A parser converts your page into a single stream of text, then tries to work out what belongs to what. It succeeds or fails on one question: is there exactly one sensible reading order?

That's it. Not "is this a table." Not "does this look designed." Just: can the text be read in one order without scrambling meaning.

Columns: the real risk

This is the one worth taking seriously.

When your layout puts a sidebar beside the main body, the extracted text may interleave the two. A line of skills, a line of job description, another line of skills. On the page it's two tidy columns. In the parsed record it can be a single scrambled stream where your job title has a certification wedged into the middle of it.

The failure is quiet. Nothing errors. The resume simply arrives describing something slightly nonsensical, and no one tells you.

How likely is it? It varies by system, which is exactly the problem — you can't know which one an employer runs. Modern parsers handle two columns better than they used to. Older and heavily customised installations still get it wrong. You're gambling on infrastructure you can't see.

What to do: for anything you're submitting through a portal, use a single column. Keep the two-column version for direct email to a named person, or for a printed copy you hand over. Our single-column templates exist for the portal case.

Tables: mostly fine, with two exceptions

Tables have a worse reputation than they deserve. Most current parsers read a simple table left-to-right, row by row, and get it right — a two-column table of dates and job titles usually extracts cleanly.

Two cases still cause trouble:

Nested tables, or tables used to lay out the entire page. If your whole resume is built inside one big table with cells for each section, you've effectively built a multi-column layout, and you inherit the column problem above.

Merged cells, which break the row-by-row assumption. A cell spanning two columns can cause the parser to lose track of which value belongs to which field.

What to do: a simple table for something genuinely tabular — skill ratings, a certification list with dates — is generally safe. Using tables as an invisible page-layout grid is not.

Text boxes: worse than either

Worth naming, because people reach for these when avoiding tables.

Text inside a text box is frequently skipped entirely by parsers, not merely reordered. This is how contact details go missing from an otherwise well-parsed resume: the name and email sit in a designed box at the top, the box gets ignored, and the record has no way to reach you.

Of the three, this is the one that fails hardest.

Quick reference

How to check yours in one minute

Open your exported file, select all the text, copy it, and paste it into a plain text editor.

What you see is close to what the parser sees. If your sections come out in order and nothing is interleaved, your layout is fine regardless of how it's built. If a skill appears in the middle of a job description, you've found a column problem. If your name or email is missing entirely, you've found a text box.

That test beats every rule of thumb on this page, including mine, because it tests your actual file rather than a generalisation about layouts. The full version adds four more checks and still takes under five minutes.

Frequently asked questions

Will an ATS reject my resume for using columns? It won't reject it. The realistic failure is subtler: your content gets filed incorrectly, so you don't appear in a recruiter's search. That reads to you as silence, not rejection.

My resume looks great in two columns. Do I really have to change it? For portal submissions, I'd change it. For a resume you're emailing to a named person who will open it themselves, the layout risk mostly disappears — a human reads columns fine. It's worth keeping both versions.

Are tables safe in Word specifically? File format isn't the variable; structure is. A table behaves the same way whether it's in a .docx or exported to PDF. Which format to send is a separate question, covered in our PDF versus Word guide.

What about a two-column skills list at the bottom of a single-column resume? Generally fine. A short list of short items has no long sentences to interleave, so even if the order shifts slightly the meaning survives. The risk is concentrated in layouts where a sidebar runs alongside full paragraphs.

Does this apply to cover letters too? It applies far less, because a letter is naturally one column of prose. That's why our cover letter templates don't need a separate ATS-safe category — the format doesn't invite the problem.