Does ATS Software Really Reject 75% of Resumes?

A statistic with no footnote

"ATS software rejects 75% of resumes before a human ever sees them." You've read this exact sentence, or something close to it, on dozens of resume-advice sites, in LinkedIn posts, and in the intro paragraph of tools that then try to sell you a fix for the problem they just invented. It has the shape of a real finding: specific, slightly alarming, oddly precise. That shape is doing a lot of work, because the substance behind it is thin to nonexistent.

We went looking for where it came from. Not casually: we tried the things you'd try if you were fact-checking a claim for a living, searching for the original study, checking whether any of the sites repeating it linked to a source, looking for a vendor report, a survey methodology, anything with a number attached to a name. What we found instead was the number, repeated, citing nothing, or citing another site that also cited nothing.

That doesn't mean nothing is wrong with how resumes get processed. It means the real problem is more specific, more mechanical, and, this is the useful part, considerably easier to fix than outsmarting a hidden algorithm.

What applicant tracking software is actually for

The name does a lot of the misleading here. "Tracking system" sounds like security software, something built to screen people out. In practice, most ATS platforms are closer to a filing cabinet with a search bar. A recruiter posts a job, applications land in a shared queue, and the software's job is to store them, make them searchable, and let a human sort through the pile faster than a stack of paper would allow.

The decision to move someone forward is almost always still made by a person looking at a list. The software's contribution is building that list, and building it accurately depends entirely on correctly reading what's in your file, which is the part that actually goes wrong.

How a parser turns your resume into data

Strip away the acronym and what's happening is a text-extraction problem: software opens a PDF or Word document, walks through the content, and tries to sort it into fields (name, email, phone, job titles, dates, skills), the same way you'd sort a pile of receipts into categories by hand, except automatically and without judgment about what's obviously a name versus what's obviously a job title.

Most parsers do this by reading position on the page, roughly left to right and top to bottom, the way you'd read a single column of newspaper text. They're pattern-matching against layout and formatting cues, not comprehending your resume the way a person would. That's a completely reasonable way to build fast, cheap parsing software. It also means that the moment your document's visual layout stops matching "single column, top to bottom, plain text," the gap between what you see and what the software extracts starts to widen.

Why PDF and Word files behave differently

Part of why that gap exists comes down to what a file format is actually built to store. A Word document is, structurally, a document: paragraphs and headings exist in the file as a linear sequence, in the order you typed them, tagged with what kind of block each one is. A PDF is built to solve a different problem: making a page look identical no matter what device opens it. Underneath, it's often a set of instructions for placing individual characters at specific coordinates on a page, closer to a printing press layout than a document outline. Some PDF exporters preserve reading order alongside those coordinates, and some don't, which is why two resumes that look pixel-identical on screen can extract completely differently depending on which program generated the file.

None of this is a reason to avoid PDF. Most employers expect one, and a well-structured single-column PDF parses fine. It's a reason to actually check the file you're submitting instead of assuming "PDF" is one predictable format.

Where that gap actually shows up

Multi-column layouts

This is the big one. A resume with skills in a narrow left column and experience in a wider right column looks perfectly organized to a human eye. A parser reading by position on the page doesn't see two columns. It sees text at various coordinates, and depending on how it walks the page, it can jump from the bottom of your skills list straight into the middle of a job description.

Here's what that actually looks like in practice. Toggle between the two views below: how you laid the resume out, and roughly what a parser reading by page position extracts from the same file.

Nobody wrote that second version. Nobody would. But it's a coherent, predictable output of a reasonable parsing strategy meeting a layout it wasn't designed for. This isn't a bug in the software being unfair to you. It's two systems, your design sense and the parser's reading order, that were never talking to each other in the first place.

Missing text layers

Export a resume as a flattened image, or scan a printed copy back into a PDF, and you get a file that looks identical to a text-based one but contains zero selectable text underneath. Try to highlight a word in it and you can't, because there isn't one there to highlight, just pixels arranged to resemble letters.

A parser reading that file doesn't extract a garbled or partial version of your resume. It extracts nothing. Not "nothing important," nothing at all, the digital equivalent of a blank page. And because the file still looks fine when you open it and read it on screen, this is easy to miss unless you check for it directly.

Content trapped in headers, footers, and text boxes

Contact information tucked into a header or footer region, or a name placed inside a text box or table cell rather than the main document body, falls into an inconsistent zone. Some parsers read it, some skip it entirely, depending on how the file was structured under the hood. If your phone number lives in a part of the document that gets treated as decoration rather than content, it may as well not be there.

Section headers a parser doesn't recognize

"Where I've Worked" reads fine to a person. A parser trained to look for something closer to "Experience" or "Work History" may never make the connection, and file the whole section as unstructured text instead of the structured employment-history field it was supposed to land in.

Icons standing in for words

A phone icon next to a number, a mail icon next to an email address: visually clean, and often invisible to a parser that doesn't process glyph-based icons as meaningful content. The icon disappears, and the number sits there without the label that told a human what it was.

Why the myth is so sticky

None of the actual failure modes above make for a good headline. "Your two-column layout might reorder two lines" is true and useful and doesn't generate clicks the way "75% of resumes get automatically rejected" does. A vague, large, scary number creates urgency; a specific, checkable issue creates a to-do item. It's also a genuinely convenient stat for anyone selling a fix: if the software is secretly rejecting three out of four people, you need a tool, urgently, no matter what it costs. If the real issue is checking whether your layout extracts cleanly, that's a five-minute problem, not a fear to be managed.

There's a second reason the number survives, and it has nothing to do with marketing: it's close to impossible to disprove from where a job seeker sits. If you apply to fifty jobs and hear back from twelve, you have no way of knowing whether the other thirty-eight were read by a person and set aside, never extracted correctly, or simply went to someone who was a better fit. The silence looks the same either way.

A five-minute self-test

You don't need a tool, ours or anyone else's, to catch most of what's covered above:

1. Select all the text in your resume and paste it into a plain text editor. If your skills, job titles, and dates come out scrambled or interleaved, a parser will likely read it the same way.
2. Try to highlight a single word of body text with your cursor. If nothing highlights, there's no text layer, and the file is unreadable to any automated system.
3. Check whether your contact information sits inside a header, footer, or text box. If it does, move it into a normal paragraph near the top of the page.
4. Look at your section headings. A non-standard label like "Career Journey" instead of "Experience" rarely costs you anything stylistically, and it's safer for parsing.
5. If you used icons next to your phone number or email, make sure the actual text is still there beside the icon, not standing in for it.

What to check instead of chasing a score

None of this requires guessing at a hidden algorithm, because there isn't one to guess at. It requires knowing what your specific file actually contains once software reads it back to you: is there a real text layer, does your layout hold up outside of columns and tables, do your contact details and section headers land in the fields they're supposed to.

That's the entire premise of a parse-check: not a score standing in for a black box, but the actual extraction, shown plainly, so you're fixing a real and specific problem instead of guessing at an imaginary one.

FAQ