ATS-friendly resume format: what actually breaks the parse
Most advice about beating applicant tracking systems is folklore. Here is what genuinely garbles a parse, what makes no difference, and how to check your own file in two minutes.
Updated 2026-08-05 · 5 min read
There is a genre of resume advice that treats applicant tracking systems as a hostile intelligence you have to trick. Stuff white keywords behind the margin. Never use bold. Submit only .docx. Almost all of it is wrong, and some of it will get you rejected by a human for looking strange.
An ATS is much less exciting than that. It is a database with a résumé parser bolted on the front. The parser's job is to take your file, find the text, and guess which chunk is your name, which is your last employer, and which are your skills. When people say a resume "failed the ATS", what happened in almost every case is that the parser guessed wrong and put your work history into the wrong fields — or found no text at all.
So the useful question is not "how do I beat the robot". It is "what makes a parser guess wrong". There are four answers, and they are all about layout, not wording.
1. A PDF with no text layer
This is the one that actually kills applications, and it is the most common failure in the resume-builder category. There are two ways to make a PDF. You can write text objects into the file, in which case the words are really in there and any parser can pull them out. Or you can render the page to an image and wrap the image in a PDF, in which case the file contains a picture of your resume and no words at all.
Both look identical on screen. One is invisible to every parser that does not run OCR.
You can check yours in five seconds: open the PDF and try to select a line of text with your cursor. If you can highlight individual words, there is a text layer. If your cursor draws a selection box over the whole page like it would over a photo, you have an image, and you should export it again from something that produces real text.
The same test catches resumes exported from design tools with the wrong setting, and scans of a printed copy.
Every PDF from the builder on this site is text-based, using the standard PDF fonts. That is why the files come out around 14 KB instead of several megabytes — there is no image in them.
2. Multiple columns
A two-column layout with a skills sidebar looks efficient and reads well to a human. To a parser reading the text stream, it is often a disaster, because the reading order stored in the file may run straight across the page rather than down each column.
When that happens, "Senior Analyst" on the left and "Python, SQL" on the right become a single line reading Senior Analyst Python, SQL, and your job titles get shredded into your skills list. Some modern parsers detect columns correctly. Many, including ones still running at large employers, do not.
This is a coin flip you gain nothing from taking. A single-column resume can hold exactly as much information; it just runs down the page instead of across it. Every template on this site is single-column for that reason.
3. Tables, text boxes, and headers
Three related problems, all with the same cause: the text is technically not in the body of the document.
Tables turn each cell into a separate parse unit. A skills table with three columns often comes out as nine disconnected fragments in an unpredictable order.
Text boxes in Word float above the page rather than sitting in the text flow. Some parsers skip their contents entirely.
Page headers and footers are the cruellest version, because this is where a lot of people put their contact details to save space. Several parsers read only the document body and never touch the header region — so the resume arrives with no email address, and the system marks the profile incomplete.
Put your name, email, phone and location in the first lines of the body. Nowhere else.
4. Graphics doing semantic work
Icons instead of the words "Email" and "Phone". A skills section made of five-dot ratings. A timeline drawn as a graphic. A photo.
None of this carries information the parser can read. The dot rating that says you are 4/5 at Python conveys, to the database, nothing whatsoever. Worse, icon fonts sometimes resolve to random Unicode characters, so your contact line arrives as ✉ maya@example.com rendered as \uF0E0 maya@example.com.
If a piece of information matters, write it as a word.
What does not matter as much as people think
Bold and italic. Fine. Parsers strip formatting; they do not choke on it.
File type. PDF and .docx both parse well, provided the PDF has a text layer. Submit whatever the posting asks for. If it does not specify, PDF is safer because it will not reflow on someone else's machine.
Standard section headings. "Experience" is safer than "Where I've Made An Impact", but this is a small effect and mostly matters for the auto-fill step. Use the boring word anyway — you gain nothing from the clever one.
Fancy fonts. A parser reads the character codes, not the shapes. Unusual fonts are a human-readability question, not a parsing one.
Keyword stuffing in white text. This does get caught, and being caught looks like deliberate deception. Do not.
The two-minute self-check
- Open your PDF and try to select a sentence with the cursor. Words highlight individually? Good.
- Select the whole document, copy it, and paste it into a plain text editor. Read what comes out.
That paste is roughly what the parser sees. If your job titles are interleaved with your skills, you have a column problem. If your email is missing, it is in a header. If a section is absent, it is in a text box. If you get a wall of nothing, there is no text layer.
That second step is worth more than every list of "ATS-friendly fonts" on the internet, because it shows you your actual file rather than a general rule.
Once the format is safe, the words matter
Passing the parse is a floor, not an advantage. Every competent applicant clears it. What separates resumes after that is whether the text matches what the posting is asking for, in the posting's own vocabulary — parsers and the recruiters searching the database both match on strings.
Our ATS keyword checker does that comparison: paste the posting and your resume and it extracts the terms the posting weights heavily, then tells you which are missing from your text. And if you want a file that is text-based and single-column without thinking about any of this, the builder produces one by default.