Why the Same Resume Parses Differently

Send the same file to two employers and you can get two different parsed records. The extraction library, the version, the vocabulary, and the employer’s own configuration all differ, and each of them changes the outcome. That is why advice framed as “the ATS does X” is unreliable, and why the only durable strategy is a document with few enough ambiguities that every reasonable implementation agrees.

Source 1: the text extractor

Before any resume-specific logic runs, something has to pull text out of the file. There are several widely used libraries for this, they have different heuristics, and PDF extraction in particular is genuinely hard — a PDF stores positioned glyphs rather than paragraphs, as described in what a resume parser actually sees.

Where extractors differ:

Column detection. Some attempt to identify columns and read each in turn; others sweep line by line across the page. On a two-column layout these produce completely different text.
Header and footer handling. Included, collected separately, or dropped.
Text boxes and shapes. Read in place, appended at the end, or skipped.
Table handling. Cell by cell in row order, or column order, or flattened with delimiters.
Ligatures and glyph mapping. An fi ligature or a subsetted font can extract as a missing character, turning financial into nancial.
Line rejoining. Whether a word hyphenated at a line break is put back together.

None of that is visible to you when you look at the page.

Source 2: the version

The same product changes over time. A resume that parsed cleanly in one release can parse differently after an upgrade, and employers upgrade on their own schedules. This is one reason claims about how a specific named system behaves age badly — and one reason this site does not make them.

Source 3: the vocabulary and taxonomy

Skills matching depends on a dictionary, and title matching on a taxonomy. Both are maintained assets, and both differ:

A newer vocabulary knows newer tools. An older one does not know a technology that appeared last year.
Some vocabularies carry rich synonym sets; others carry bare terms.
Some employers extend the vocabulary with their own industry terms.
Title taxonomies differ in granularity and in how they handle seniority.

So whether your K8s resolves is a property of the employer’s dictionary, not of your resume. Writing both forms once, as in acronyms, synonyms, and spelling variants, is how you stop caring which one they have.

Source 4: the employer’s configuration

This is the largest and least discussed source of variation. A system is a set of capabilities; what an employer switches on is a separate decision, and it varies by company, by team, and by role.

Configurable in most systems:

Which fields are required, and which are knockouts.
Whether any automated ranking runs at all — many employers do not enable it.
The screening questions on the form, written per requisition.
Whether recruiters search the database or work only from new applications.
Whether rejected candidates stay searchable.

Two companies running identical software can therefore behave in almost unrelated ways. When someone tells you what “the ATS” does, they are usually describing one configuration of one version of one product, honestly reported and not generalisable.

What this rules out

Optimising for a named system. You do not know which one you are facing, which version, or how it is set up. Advice keyed to a specific vendor is a guess dressed as precision.

Believing any universal number. Rejection rates, score thresholds, seconds-per-resume figures. These are repeated everywhere and traceable to nothing you can inspect, and the variation above makes a single figure incoherent even in principle.

One-off testing as proof. If you run your file through one checker and it comes out clean, you have learned that one extractor handled it. That is genuinely useful and not the same as a guarantee.

What it argues for: minimise ambiguity

The strategy that survives all four sources of variation is to remove the decisions. Every place your document requires an extractor to guess is a place two extractors can disagree.

One column, top to bottom. No column-detection decision to get wrong.
No tables, text boxes, or shapes. Nothing whose ordering is implementation-dependent.
Contact details in the body. No header-handling decision.
Standard section headings. No classification guess.
Dates adjacent to their jobs. No attachment guess.
Skill names in plain text, both short and long forms once. No vocabulary dependency.
Real text, never an image. No optical recognition step.
A common font, embedded normally, no exotic ligatures. No glyph-mapping failure.

Every item on that list removes a fork in the road. A document with no forks parses the same way everywhere, which is the closest thing to a guarantee available.

Note that none of it requires an ugly resume, and none of it is a trick. A single-column document with clear headings and dates next to jobs is also the easiest version for a person to read.

Testing across implementations

You cannot test against employers’ systems, but you can widen your sample cheaply:

Copy-paste to plain text in your editor. This is your baseline: roughly what a line-sweeping extractor produces.
Open the PDF in a different reader and copy again. Different readers use different extraction paths, and a discrepancy between the two is a warning sign.
Save as plain text from your word processor and compare against both.
Try more than one free checker if you use them, and treat disagreement between them as the useful signal rather than either score.

What you are looking for is not a clean pass. It is agreement. If three extraction paths produce the same ordered text, the fourth one you cannot test probably will too. If they disagree, you have found a construct in your document that requires guessing — and removing it is the fix. The procedure is expanded in how to test your resume like a parser would.

A note on file format

Format choice interacts with all of this: DOCX carries explicit paragraph structure, PDF carries positioned glyphs, plain text carries nothing but text. That is a whole subject on its own, covered in file formats: PDF, DOCX, and plain text. The short version is that if the form does not specify, the safest file is the one whose structure is least dependent on inference.

Check it

Run steps 1 to 3 above on your current resume and diff the three outputs — even by eye. Every difference marks a place where implementations will disagree about you, and each one traces back to a specific construct on the page. Fix the constructs, not the wording.