ATS
The formatting that breaks parsing — and the myths that do not
The formatting choices that genuinely break resume parsing, the ones that are harmless myths, and how to test your own file in under five minutes.
The short answer: Only a handful of formatting choices genuinely break resume parsing, and most of the advice circulating about it is myth. What actually causes damage: multi-column layouts, text in headers and footers, content inside images or text boxes, tables used for layout, and non-standard section names. What is harmless despite the folklore: PDFs, bullet points, bold text, colour, and a sensible amount of white space. The five-minute test that settles it for your own file is to save it as plain text and read the result — if the plain-text version is coherent and in the right order, so is the parsed record.
Key points
- Multi-column layouts are the single most damaging choice, because a parser reading left to right can interleave two columns into nonsense.
- A text-based PDF is fine and has been for years; the advice to always use .docx is a decade out of date for most systems.
- Anything in a header, a footer, a text box or an image may simply not exist in the parsed record, contact details included.
- Use the standard section names — Experience, Education, Skills — because parsers segment on them and creative headings defeat that.
The five choices that genuinely break a parse
Formatting risks, ranked by how often they cause real damage| Choice | What goes wrong | Fix |
|---|
| Two-column layout | A parser reading in document order can interleave the columns, producing alternating fragments | Single column, full width |
| Header / footer content | Header and footer regions are often skipped entirely — including contact details placed there | Put contact details in the body, on the first line |
| Text inside an image | Images contain no text; a graphical skills chart contributes nothing to the record | Write the same information as text |
| Tables used for layout | Cell order does not always match visual order, so dates can detach from the roles they belong to | Plain paragraphs and lists |
| Creative section names | Parsers segment on conventional headings; "My Journey" is not recognised as Experience | Experience, Education, Skills |
These have one thing in common: each of them creates a difference between what the page looks like and what the file contains in order. The parser only ever gets the second one.
What does not matter, despite the advice
- PDFs. A text-based PDF parses fine. The exception is a scanned or exported-as-image PDF, which contains no text and fails completely — check by trying to select a word in it.
- Bullets, bold and italics. All standard, all parsed, all worth keeping because they make the document readable.
- Colour. A restrained accent colour is irrelevant to a parser and pleasant for a reader. Colour used to carry meaning is a different problem, and an accessibility one.
- Keyword density. A term is present or absent. Repetition adds nothing and costs readability.
- File name. It is stored, not scored. Name it after yourself so a recruiter can find it on their desktop — that is the only real reason it matters.
The five-minute test
Rather than reasoning about what a parser might do, look at what it gets. Export your resume to plain text and read the output top to bottom. It is an approximation, but it catches every one of the failures in the table above.
- Are your name, phone and email in the first few lines? If not, they are probably in a header.
- Does each role sit next to its own employer and dates, in order? If they have detached, a table or column layout is the cause.
- Is any content missing entirely? Whatever is missing was in an image, a text box or a shape.
- Do the section headings appear as words on their own lines? If they were drawn as graphics, they are gone.
- Does the whole thing read in a sensible order? If it does, stop optimising and go back to the content.
Once the file parses cleanly, formatting has stopped being your constraint, and the remaining work is editorial — which is where nearly all of the real gains are. Turning responsibilities into evidence is the change that actually moves an application forward.
Frequently asked questions
Is a PDF or a Word document safer?
A text-based PDF is fine for essentially every modern system, and it has the advantage that it renders identically for the human who eventually opens it. The one PDF that fails is a scanned or image-based one, which contains no text at all. Use .docx if the application explicitly asks for it — that instruction sometimes means their parser is old, and it costs nothing to comply.
Do bullet points and bold text cause problems?
No. Standard bullet characters and bold or italic text parse without difficulty and make the document far more readable for the person who matters. The advice to strip all formatting produces a wall of text that survives parsing perfectly and then loses at the human stage, which is the stage that decides.
How do I test my own resume in five minutes?
Open the file, save or export it as plain text, and read what comes out. That approximates what the parser sees. If your contact details are missing, if two columns have merged into alternating fragments, or if the order has scrambled, you have found a real problem. If it reads as a coherent document, your formatting is not what is holding you back.
Published 2026-08-01 · Updated 2026-08-01