What actually breaks ATS résumé parsing: tables, headers, columns, and icons
Four layout choices break résumé parsing more than anything else: tables, text in headers and footers, multi-column layouts, and icon fonts. They break for mechanical reasons — a parser reads your file as one linear stream of text, and anything that only works visually gets scrambled or dropped. We build a résumé parser, and this guide shows you the actual broken output each one produces.
Why do parsers read résumés differently than humans?
A human looks at your résumé as a two-dimensional page: eyes jump between columns, connect a label on the left with a value on the right, and skip decorations. A parser gets none of that context: typically it receives your file as one flat sequence of text — first line, second line, third line — and everything downstream (which words count as your job title, which section your bullet points belong to) depends on that sequence being right.
Every problem in this guide is the same problem wearing different clothes: the order things are stored in is not the order they appear in.
Tables: read in the wrong order
In a document file, a table is not a picture of a grid — it is a list of cells stored row by row. When a parser flattens it into text, your careful visual arrangement collapses into cell-by-cell order. A skills table that looks organized to you might come out like this:
Languages Tools Python, SQL Tableau, Excel Spanish (fluent) Git
Now "Spanish (fluent)" sits in the same row as "Git," and a parser trying to file your skills has no idea which column a value belonged to. Dates in one column and job titles in another suffer the same fate — the pairing that existed visually is gone from the text.
The fix: anything a system must read in order — experience, skills, education — belongs in plain paragraphs and bullet lists, not cells.
Headers and footers: where contact info goes to die
Word processors store header and footer content in a separate part of the file, away from the body text. Many parsers read only the body. If your name, email, and phone number live in the document header — a very common template design — a parser can extract your entire work history and still have no idea how to contact you.
The cruel part is that this failure is invisible to you: the résumé looks complete, prints complete, and the words are technically "in the file." They are just in a compartment that automated systems routinely skip.
The fix: put your name and contact details in the first lines of the document body. The header is fine for page numbers — nothing more.
Multi-column layouts: interleaved lines
Here is a secret about typical résumé PDFs: there is no such thing as a "column" inside them. A PDF stores characters and their coordinates on the page — ink positions. Any parser reading it has to guess the reading order from those positions, and a two-column layout is where the guess goes wrong: many parsers sweep the page top to bottom and stitch lines from both columns together.
SKILLSSeasoned marketing professional Python · SQLwith 8 years of experience leading Tableaucampaigns for retail brands…
Sidebar fragments interleave with your summary, sentence by sentence. Some modern parsers reconstruct columns correctly — but you do not get to choose which parser reads your file, so the safe assumption is the pessimistic one.
The fix: one column, top to bottom. If a posting's system renders your file for human review, the design version can shine there — but the machine-read copy should be linear.
Icons and decorative glyphs: 📱 becomes garbage
Design templates love icon fonts — a little phone glyph before your number, an envelope before your email. Inside the file, those icons are characters from a symbol font, and parsers commonly mishandle them in one of two ways: they turn into garbage characters (□ or ?) or into the icon's internal name. This is real output we have seen from a designed résumé:
□ (+82) 10-9030-1843 | □ [email protected] | HOUSE-CHIMNEY www.example.com | GITHUB-SQUARE username | LINKEDIN username
The literal strings "HOUSE-CHIMNEY" and "GITHUB-SQUARE" — the font's internal glyph names — became part of the résumé text. The contact details survived here, but a parser looking for a labeled phone field has to fight through noise.
The fix: plain text labels. "Email:", "Phone:", or nothing at all — an email address is recognizable by shape.
How do I check my own résumé?
You do not have to take our word for any of this — every example above is reproducible. Upload your résumé to a checker that shows you the raw extracted text in reading order, and read it like a proofread: if the lines are out of order, if your contact info is missing, if icons turned to garbage — that is what a parser received from your file, and an ATS performs the same class of read.
See what a parser extracts from your résumé
Free keyword match against any job posting, no sign-up. The full read-through shows the exact text a parser pulls from your file, in reading order.
Check my résumé →Are tables always bad for ATS parsing?
For anything a parser must read in order — your work history, skills, dates — yes, avoid them. A table is stored cell by cell, so the reading order is decided by storage, not by your visual layout. A purely decorative table with no important text is survivable, but there is rarely a reason to risk it.
Is a two-column résumé ever safe?
Some modern parsers reconstruct columns correctly, some interleave the lines. Because you cannot control which parser reads your file, a single column is the only layout that does not lean on the parser's column logic at all. If you love your two-column design, keep it for humans and submit a single-column version to application systems.
Do modern ATS handle these problems better?
Newer parsers are better at columns and some handle tables, but the market runs on a long tail of older systems, and you never know which one is behind a job posting. The layouts in this guide fail on the systems that are worst at recovery — which is exactly the case you should plan for.