Buy Now
Log inBuy Now

Can ATS Read Tables, Columns, and Headers? The Honest Answer

Some parsers handle a simple table. Some don't. You never know which one you're up against, and that's the whole reason the safe answer is a single column with no tables.

Can ATS Read Tables, Columns, and Headers? The Honest Answer

Can ATS Read Tables, Columns, and Headers? The Honest Answer

Can ATS read tables? Not reliably, and that's the problem. Some parsers handle a simple table, many scramble it, and you never know which one you're facing. Columns break read order the same way, and document headers and footers often get skipped entirely. Standard section headings like "Experience" are the one "header" every parser reads well.

So the safe resume is boring on purpose: one column, no tables, no text boxes, nothing important in the header or footer. That's not a style opinion. It's risk math.

Key Takeaways

  • Tables: some parsers read simple ones, many scramble cell order. You can't pick which ATS you get, so skip them.
  • Columns: parsers read left to right across the full page, so two columns interleave and merge.
  • Document headers and footers: plenty of parsers ignore them. Keep your name and contact info in the body.
  • Section headings: parsers read them fine when they're standard words like Experience, Education, and Skills.
  • Test any file in 60 seconds: copy all, paste into a plain text editor, read what comes out.

Why "it depends" is the wrong answer to trust

Search this question and you'll find two camps. One says modern ATS handles tables fine. The other says tables kill your resume. Both are partly right, which makes both useless.

Here's the actual situation. There isn't one ATS. There are dozens of systems, plenty of companies run older versions, and many plug in third-party parsers on top. A table that parses cleanly in one system comes out as soup in another. You don't get to choose which one reads your application.

When you can't control the reader, you build for the worst one. Harvard Business School's research on hidden workers found that a large majority of employers say their screening software filters out qualified candidates (HBS). A layout that might parse is a bet you don't need to make.

Tables: the cell order problem

A parser turns your file into one long text stream. A table isn't a stream. It's a grid, and the parser has to guess what order to read the cells in.

Some read row by row. Some read column by column. Some drop empty cells and shift everything after them. Take a typical experience table with dates in the left cell and job details in the right. Parsed badly, it reads like this:

Jan 2022 Jun 2019 Senior Analyst Analyst Brooklyn Navy Yard
Corp Harbor Logistics Present Dec 2021

Every word is technically there. None of it is usable. The extractor can't tell which title goes with which company or which dates. Your seven years of experience get scored as noise.

Tables also hide in places you don't expect. Lots of templates use invisible tables to line up dates on the right margin. You never see the borders, but the parser sees the grid. If your dates line up perfectly, check how.

Columns: the interleaving problem

Two-column resumes are the most popular layout in template stores and one of the most common ways to break a parse.

The parser reads across the full page width, left to right, top to bottom. It doesn't know your sidebar is a separate thing. So line one of your skills sidebar merges with line one of your work history, and line two with line two, all the way down.

Picture Priya, a product marketer in Brooklyn with a clean two-column resume. Her sidebar lists "SQL, HubSpot, Figma." Her main column lists her title, "Senior Product Marketing Manager." Parsed, her title can come out as "SQL Senior Product Marketing HubSpot Manager." The system now can't find her job title, and the posting asked for exactly that title.

Some parsers detect columns and read them in order. Many don't. Same risk math as tables: you can't pick your parser, so you don't give it the chance to fail. Our ATS-friendly resume template guide covers the full single-column spec.

Headers: two different things with one name

"Header" means two things in resume advice, and the answers are opposite.

Section headings: yes, read them, and use them. "Experience," "Education," "Skills," "Certifications," "Summary." Parsers lean on these words to sort your content into fields. Standard words are load-bearing. "Where I've Made an Impact" is a heading the extractor might not recognize, and everything under it can land in the wrong field or nowhere.

Document headers and footers: keep important information out. This is the repeating area at the top and bottom of every page that Word and Google Docs let you edit separately. Plenty of templates park your name, phone, and email there. Plenty of parsers never look there. The result: a candidate with no contact information, scored and stored that way.

The fix costs nothing. Put your name and contact line as the first lines of the document body. A page number in the footer is fine. Anything you need the system to know is not.

Text boxes, icons, and other quiet failures

Tables and columns get the attention, but three smaller elements break parses just as often:

  • Text boxes. They float outside the main text flow. Parsers routinely skip them.
  • Icons for phone, email, and location. Icons aren't text. Some parse as random characters, some as nothing.
  • Skill bars and rating dots. "Python: 4 of 5 dots" means nothing to a parser. It reads as blank space.

We cover the full list in what the ATS actually flags.

The 60-second test for your own file

Don't trust any of this blindly, ours included. Test your actual file:

  1. Open your resume.
  2. Select all and copy.
  3. Paste into a plain text editor like Notepad or TextEdit.
  4. Read it top to bottom.

If your name and email are missing, they're in a header, footer, or text box. If your titles, companies, and dates arrive jumbled, a table or column is breaking read order. If whole sections vanish, something is floating outside the text flow. Fix the source and paste again.

This is the same test from our PDF vs DOCX breakdown, and it works for both formats. It's not a perfect simulation of every parser, but it catches the failures that matter most.

The bottom line

Can ATS read tables? Sometimes. Can ATS read columns? Sometimes. Can it read your document header? Often not. "Sometimes" isn't good enough when one bad parse drops you before a human sees your name.

Build one column, no tables, no text boxes, standard section headings, and contact info in the body. Then spend your effort where it moves the score: language matched to the posting.

Gate Crashers does both halves. Every session turns one job posting into three tailored resume versions and a 12-question interview prep guide, delivered in DOCX and PDF on a minimal template with no tables and no columns. $4.99 one time for three sessions. No subscription, no card on file.