What actually breaks a resume in an ATS

An applicant tracking system is the software an employer uses to receive, store and search applications. Greenhouse, Workday, Lever, iCIMS and Taleo are the common ones. It ingests your file, extracts the text, tries to map that text onto structured fields — name, employer, dates, titles — and stores the result so a recruiter can search it later.

That is the whole job. It is closer to a filing cabinet with a search box than to a gatekeeper. Understanding this collapses most of the anxiety around the topic, because it tells you exactly what can go wrong: the extraction can mangle your text, and the search can fail to find you.

You will read, constantly, that applicant tracking systems automatically reject 70 or 75 percent of resumes before a human sees them. That figure has no credible source. It is repeated between resume-service marketing pages, each citing the last, and it does not describe how these systems are configured in practice.

Most systems do not auto-reject on content at all. Where automatic filtering exists it is usually explicit knockout questions the employer wrote — work authorisation, a required licence, a minimum years figure — that you answered yourself in the application form, not an inference drawn from your resume prose.

This matters practically: it means the fix is rarely “beat the algorithm”. It is “be findable and be readable”.

These are the failures that show up when you actually extract text from a rendered document and read what comes out:

File format is mostly a solved problem. A text-based PDF and a .docx both extract fine in every mainstream system; the rare exception is an employer whose upload form names one explicitly, in which case do what it says. What does not extract is a PDF that is really a scan — an image of a document with no text layer at all.

Fonts do not need to be Arial. Any common, real typeface extracts cleanly. The risk is not the font's name, it is decorative glyphs and unusual ligatures.

Colour, a horizontal rule, a modest logo — none of these break extraction. Design is not the enemy. Columns are.

One page versus two is a readability judgement for a human, not a parsing constraint. Nothing rejects you for a second page.

Once your resume is in the database, a recruiter searching for candidates types terms into a search box. That search is plain full-text matching: exact strings, no stemming, no synonym expansion. “Manage” does not return “managing”. “Postgres” does not return “PostgreSQL”.

This is the mechanism behind keyword advice, and it is much narrower than the folklore. Nothing is scoring your resume against the posting. Someone is searching, and either the string is in your document or it is not.

The practical consequence: write the term the way the posting writes it, and where a tool is commonly written two ways, include both once.

You do not need a tool to do the most valuable test. Open your resume, select all, copy, and paste it into a plain text editor — Notepad, TextEdit in plain-text mode, or any code editor.

Read what comes out. That approximates what the system stores. If the columns have interleaved, if your name is missing, if bullets have glued themselves to the first word, if dates have vanished — you have found your problem, and it will be a layout decision, not a wording one.

If everything reads cleanly in order, your document is fine and you should stop worrying about parsing and go back to the content.

No applicant tracking system publishes its tokenizer or its ranking behaviour, which means no checker — ours included — can tell you your true probability of passing a specific employer's system. Any product that shows you a percentage and implies it predicts a callback is selling you a number it cannot justify.

What a checker can honestly do is compare your document against a specific posting's vocabulary, and flag the mechanical defects above. That is useful and it is limited, and the two should never be confused.