An applicant tracking system never sees your resume as a page. It sees whatever its PDF parser could extract, run through a set of pattern matchers looking for names, dates, job titles, and skills. When a recruiter says a candidate "wasn't a match" and the resume was clearly relevant, the actual failure often happened earlier, inside the parser, on a layout choice that looked perfectly fine on screen.
What an ATS actually does with your file
Most systems run a two-stage pipeline: extract text from the uploaded file, then parse that text into structured fields (contact info, work history, education, skills) using a mix of regular expressions and machine learning models trained on resume layouts. The parsing stage is only as good as the extraction stage. If the extracted text has a job title glued to the wrong date, or a bullet point missing entirely, no amount of parsing sophistication recovers the lost information, because it was never in the string to begin with.
This is why two resumes with identical content can produce wildly different ATS results. The content was never the variable. The layout, and specifically how that layout survives text extraction, was.
The layout choices that break parsing
Multi-column layouts
A two-column resume, skills and contact details on the left, experience on the right, looks organized on screen. To a parser reading glyph runs in file order rather than visual reading order, it can read across both columns line by line, producing a sentence that starts with a job responsibility and ends with an unrelated skill keyword. The parser doesn't fail loudly. It just produces a field that no longer parses as a coherent job title or date range, and that field gets dropped or misfiled.
Headers, footers, and icons
Contact information placed in a page header or footer, a common design choice for a clean-looking template, sometimes falls outside the region a parser treats as body content, because headers and footers are a distinct content stream in the PDF's internal structure. A phone number that never gets extracted is functionally a phone number that doesn't exist to the system deciding whether to advance you. Icons used in place of the words "email" or "phone" compound this: even when the surrounding text does extract, the parser has no label to attach it to and may discard the value as unclassified.
Tables and text boxes
Resume templates that place a skills section inside a bordered table or a floating text box often extract that content out of order relative to the surrounding prose, sometimes appearing at the very start or end of the extracted string regardless of where it sits visually on the page. A parser expecting a linear document structure, summary, then experience, then education, then skills, receives something reordered and may misattribute an entire section to the wrong category.
How to test your own resume
You do not need access to a specific ATS to catch these problems. You need to see what a generic text extractor sees, since that is the shared first stage every system runs before its own parsing logic. Run your resume through a PDF text extractor and read the raw output as plain text, ignoring how the original looked. Check three things specifically: does your name and contact information appear near the top and intact, does every job title sit next to its correct date range, and does each bullet point read as a complete, self-contained line rather than fused to the line above or below it.
Cleaning the extracted text
If the raw extraction looks garbled, the fastest diagnostic is running it through a cleanup pass that rejoins hyphenated words and merges wrapped lines back into full sentences. If cleaning fixes the readability but the underlying order is still wrong, meaning columns or tables are still interleaved, the fix has to happen in the source document: convert the layout to a single column, move contact details into the body text rather than a header, and replace icon-only labels with the actual words. The field guide goes into more detail on how extraction order is determined by glyph coordinates rather than visual layout, which is the root cause behind every issue described here.
None of this requires giving up a resume that looks good to a human reader. It requires checking, once, that the same resume also reads correctly to the software that sees it first.