Most advice about applicant tracking systems is written from the outside, by someone imagining what a parser probably does, then generalising. This post is written from the inside. We maintain the parsing engine behind Creatzi's resume checker: the code that opens a PDF, works out where the text sits on the page, reconstructs reading order, and reports back what it could not understand.
That engine emits a fixed set of structural hazard codes. Each one exists because we hit the failure, wrote a test fixture for it, and taught the parser to name it instead of silently mangling the document. What follows is that list. It is not a guess at what ATS software might dislike, but the exact set of problems our own reader is built to flag.
One thing to be clear about up front: "ATS" is not one product. Workday, Greenhouse, Lever, Taleo and iCIMS all parse differently, and some are considerably more forgiving than others. What they share is the underlying problem, which is turning a visual document back into structured fields. Every hazard below is a place where that translation goes wrong.
The eight hazards, and what causes each
| Hazard | What actually happens | The fix |
|---|---|---|
| Multi-column layout | Text is laid out in columns. A parser that reads strictly left-to-right across the page interleaves the columns, so a job title from the left column lands mid-sentence in a skill from the right | Single column for anything the parser must read: experience, education, dates |
| Image-only page | The page contains no machine-readable text at all: it is a scan, an exported design, or a picture of a document. Most systems read nothing from it | Export text-based PDF from the source document, never a screenshot or scan |
| Header/footer text | Repeating running heads and feet across pages. Some parsers fold that repeated text into the body, so your name or page number appears in the middle of a role description | Keep contact details in the document body, not in the PDF header/footer region |
| Hidden text | Text present in the file but invisible to a reader, set to a tiny size or positioned off the page. Sometimes used to stuff keywords | Remove it. Our parser strips it and flags it; some screening systems reject the document outright |
| Non-standard headings | No recognisable section headings, so there is nothing to anchor the sections to. "My Journey" is not "Experience" | Use the boring words: Experience, Education, Skills, Projects |
| Low text density | Very little text relative to page count, the signature of a heavily graphical or partly scanned resume | Cut decorative elements until the text carries the page |
| Table layout | Content laid out in table cells. Cell boundaries frequently do not survive extraction, so dates merge into titles | Use paragraphs and line breaks for structure, not tables |
| Truncated document | The file is longer than the reader is willing to process, so later pages are never read | Two pages maximum. Anything past that is a gamble on someone else's page limit |
The three that cause the most damage
Multi-column layouts are the single most common cause of a resume that "disappeared". The layout looks organised to a human, with skills on the left and experience on the right, and it is exactly that visual grouping that gets destroyed. Our parser reflows columns into reading order before parsing, precisely because we could not assume other systems would. If a resume needs a column to look good, keep it for the human-facing copy and submit a single-column version through the form.
Image-only pages fail completely rather than partially, which makes them easier to diagnose and worse to submit. If you can't select the text in your PDF with a cursor, neither can the parser. This catches people who design a resume in Canva or Figma and export as an image, and it catches anyone submitting a scanned printout.
Non-standard headings are the quiet one. The document parses, the text extracts cleanly, and then everything files into the wrong bucket because the section was labelled "Where I've Worked" instead of "Experience". Sections are the scaffolding a parser hangs everything else on. Creativity in the heading text buys nothing and costs a lot.
What the parser reports when it cannot find something
There is a second class of finding worth understanding, because it tells you something different. Beyond structural hazards, our engine reports what it failed to reconstruct:
- It found an experience section but could not confidently split it into individual roles, usually a dates formatting problem, or roles separated only by visual spacing
- It found an education section it could not parse
- It could not confidently identify a name at the top of the document
- No work-experience section was detected at all
We deliberately word these as our findings rather than your errors, because that is what they are: the parser's failure to read, not the candidate's failure to write. But they are also a reliable proxy. If our reader cannot find your name at the top of the page, a recruiting system's reader probably cannot either, and that field is often the primary key for your entire application record.
The dates problem nobody mentions
Splitting an experience section into discrete roles is almost entirely a dates problem. The parser is looking for a repeating pattern that marks the start of each role. When date formats are inconsistent within a single document (Jan 2023 - Present in one role, 01/2021-12/2022 in the next, 2019 to 2021 in a third), the pattern breaks and two roles merge into one.
Pick one date format and use it in every single role. It is the lowest-effort, highest-return formatting change on this entire list.
What this does not mean
It does not mean you need a plain, ugly resume. Typography, spacing, a restrained accent colour, and a well-designed header all survive parsing perfectly well, because none of them interfere with text extraction or reading order. The hazards above are all structural: columns, tables, images, headers, hidden text. Visual craft that stays inside a single-column text flow costs you nothing.
That distinction is the whole point. "ATS-friendly" has been used to sell people on stripped-down documents that look like tax forms, when the actual constraint is much narrower than that.
Check yours
You can run your own resume through the same engine described here. It reports the hazards above by name, shows what it managed to extract, and tells you where it lost confidence. Creatzi's ATS resume checker is free and does not require an account to run a check.
If you want to see how the structure looks when it is done right, the resume examples library has single-column, parser-safe layouts for 119 roles.