We Ran a Real Resume Parser Over 602 Templates. 14 Passed.

Every resume site sells the same warning: pick the wrong template and software will mangle your application before a person sees it. Columns are dangerous. Tables are dangerous. Icons, fonts, graphics — all dangerous.

Almost none of it has been measured. Our first study traced the industry’s most-repeated claim about machine screening to a company that closed in 2013 without ever publishing a study.

So we ran the test. One resume, rendered through 602 open-source templates, printed to PDF, then put through two stages: standard text extraction, and a real open-source resume parser reading the files the way hiring software does.

The content never changed. Only the design did.

The text survives almost everywhere. The meaning does not.

Of the 517 templates that render a working resume, 96% put every word into the PDF. But when a parser tried to turn those PDFs back into structured fields — this company, this job title, these dates — it recovered the complete work history from 15 of them. From 92% it recovered not one usable job.

One resume, 602 templates

JSON Resume is an open standard: a resume is a JSON file, and a template is a program that renders it. Every template consumes identical input, which is what makes this an experiment rather than a survey — hold the content fixed, vary only the design, and any difference in the output belongs to the design.

We wrote a fictional resume to the published schema: a data engineer, four jobs with employers and dates, a degree, a certificate, nine skills, a summary and eleven achievement bullets. Every distinctive name is invented — Quillfern Analytics, Halverstock University, Penhallow Grid — so a match in a PDF means the data travelled and cannot mean coincidence.

Here is the same resume, in fifteen of them.

Then two measurements. First, text extraction: read every PDF back with Poppler’s pdftotext and the Python library pypdf, and check what survived. Second, parsing: run every PDF through Open Resume‘s parser — the best-known open-source resume parser there is — and compare its structured output field by field against the truth.

One template in eight does not work at all

Before measuring what templates lose, a prior question nobody asks: how many run?

Thirty will not load. Thirty-six crash outright on a resume that validates against the schema they are built for. Six return a blank page. Thirteen render something that is not a resume — a business card, a cover letter — which is a different product rather than a failure.

Stage one: the text survives

We tracked 96 distinctive words and counted how many reached the HTML, and how many reached the PDF made from it. Those two are kept apart deliberately. A word missing from the HTML is a template choosing not to display it. A word in the HTML and absent from the PDF is the thing people actually fear.

The two medians are identical. Whatever a template decides to show, it very nearly always gets into the file, in the right order.

If the story ended here, the industry’s warning would simply be wrong. It does not end here.

Stage two: a parser reads them, and almost nothing comes back

Text in a file is not a resume. Hiring software has to decide which words are a company, which are a job title, and which dates belong to which employer. That is parsing, and it is where the damage is supposed to happen — so we measured it instead of assuming it.

The median number of jobs recovered, against a truth of four, is zero.

These are not broken templates. These are ones whose text came through perfectly.

Every one of those has at least 93 of the 96 content words sitting in the PDF. A person reads them without difficulty. The parser returned nothing it could use.

The fourteen that passed

Fourteen templates gave the parser everything: the name, the email, and all four jobs with employer, title and dates attached correctly.

They have a look, and the look is plain. Single column. No sidebar. Headings and text and nothing between them. Several are literally named short, shorter and print.

That is not an aesthetic judgement. It is the measurement:

Adding any layout machinery roughly halves the chance the parser gets your name right — 79% down to the mid-thirties — and cuts the chance of recovering a complete job by a factor of three to five.

But read the first row honestly too. Even the plainest possible layout yields a complete work history only 7.5% of the time. Both things are true at once: layout makes parsing much worse, and the parser is weak even when the layout is ideal. Anyone selling an “ATS-friendly template” is selling the first half and relying on you not knowing the second.

Two details that break machine reading on their own

Underneath the parsing result sit two mechanical failures, both invisible on the page.

An email address cut in half

Twenty-one templates put an address into the PDF that no parser can find — not missing, but broken mid-word:

A person reads that without noticing. The regular expression every parser uses to find an address — some variant of S+@S+ — returns nothing.

CSS column-count breaks the address in 19 of the 36 templates that use it. Among the 481 that do not, two do. Once you account for it, nothing else predicts the failure: flexbox 0.9%, CSS grid 0%, floats 0%, tables 0%, icon fonts 0%.

Words that cannot be searched

Our two extractors agreed about everything except two words. Both found Python, SQL, dbt, Kafka, AWS, Terraform and Kubernetes. On Apache Airflow and Snowflake they disagreed in 55% of cases. Here is what the second one returned:

That is not f followed by l. It is fl — one character, the typographic ligature. Professional fonts substitute it automatically and the PDF stores what the font drew. Only two of our nine skills contain the letter pair, which is exactly why only those two disagreed.

292 of 517 templates — 56.5% — carry ligatures in their text layer: fi in 288, fl in 278, ff in 65. Any word containing fi, fl or ff is then stored as something a plain keyword search will not match: office, workflow, fluent, staff, certification, financial, efficiency, profile, benefit, offer.

Whether those words are findable depends on whether the software reading the file normalises ligatures. The document looks identical either way.

What this cannot tell you

One parser, and a limited one

Open Resume is the best-known open-source resume parser, and its own source carries this note: “The parser algorithm only works for single column resume in English language.” It is not a general-purpose reader, and the 7.5% success rate on plain single-column layouts shows it struggling with input it was built for. A different parser would produce different rates. What it does support is the comparison between layouts, because every template met the same reader.

This is not an applicant tracking system

Workday, Taleo and iCIMS are closed products. Nobody outside those companies can test them, and any article claiming to have done so is describing a proxy or inventing. We used the most credible open proxy available and are telling you exactly which one.

These are not the templates most people use

Every template here is an open-source npm package for a developer-facing standard — 602 of them, freely inspectable, which is why the experiment is possible at all. It is not the commercial market: not Canva, not Word, not the templates inside any resume builder, ours included. The mechanisms generalise. The percentages do not.

One resume, one fictional person

Every number rests on a single document. A longer resume, or one with accented characters, would stress these templates differently. We publish the resume and the scripts.

What to do about it

Method

All 602 packages matching jsonresume-theme were enumerated from the npm registry and installed at their latest published version. The resume validates against the official JSON Resume schema including its ISO-8601 dates, and carries the legacy company key alongside the current name so that templates written against the older schema are not recorded as losing the employer.

Each template renders in its own operating-system process. Templates register Handlebars helpers, swap Moment locales and patch shared prototypes, so one loaded earlier changes how later ones behave: measured in a single shared process, the share of templates printing the employment year fell from 96.8% to 4.9% as the run progressed. That was an artefact of the harness, and isolation removes it.

PDF conversion waits for CSS animations to finish. Several templates fade content in from zero opacity; printing immediately captures them mid-animation. One yielded 77 characters when printed at once and 1,314 once its animation completed. Every page waits for document.getAnimations() to settle, capped at five seconds. Margins were tested at zero and at one centimetre and make no difference to what is extracted.

Text is extracted twice, and a word counts as present if either tool finds it. Matching is done on whitespace-stripped text, which is what separates absent from broken across a line.

For parsing, Open Resume’s parseResumeFromPdf was bundled unmodified and run in a browser context — its real code path, not a reimplementation. A field counts as correct only on an exact match after case folding: a name field containing the name with the job title glued to it is wrong, because that is what a downstream system would store. A job counts as complete only when employer, title and a date all landed on the same record.

Layout features are detected from each template’s own rendered markup and CSS. Where features co-occur, rates are reported within the group lacking the dominant one, so two correlated features cannot be credited with the same failures.

FAQ

Do resume templates actually break ATS parsing?

The text survives almost always — 96% of templates put every word of the resume into the PDF. What breaks is the structure. Running an open-source resume parser over the same files, the complete work history came back from 2.9% of templates, and 92.1% yielded not one job with employer, title and dates attached correctly. So the risk is real, but it is not the one people describe: your words are not disappearing, their relationships are.

Are two-column resumes bad for ATS?

They cost you, but less than the plain-versus-decorated distinction does. Templates with no layout CSS at all had the parser get the name right 79.1% of the time; with flexbox 36.9%, CSS grid 33.8%, floats 40.0%. Separately, CSS column-count — which flows text through narrow columns, and is not the same as a sidebar — broke the email address in 52.8% of the templates using it, against 0.4% of the rest.

What is the safest resume template format?

In this test, the plainest. Every template that gave a parser the complete resume was a single-column layout with no sidebar and no decorative structure — several are named short, shorter and print. That does not mean a designed resume is unusable; it means each layer of visual structure measurably reduces what a machine recovers.

Why can’t my PDF be searched for some words?

Most likely typographic ligatures. Good fonts replace the letter pairs fi, fl and ff with a single combined character, and the PDF stores that character rather than the two letters, so a search for “workflow” fails on a visible word. This affected 56.5% of the templates tested. Open your PDF and press Ctrl-F on a word containing one of those pairs.

Does this test real applicant tracking software?

No, and no published study does. Workday, Taleo and iCIMS are closed. We used Open Resume, the best-known open-source resume parser, and name it explicitly. Its own documentation states it is designed for single-column English resumes, which is part of why the absolute rates are low — but every template was read by the same parser, so the comparison between layouts holds.

Sources

• Open Resume — the open-source resume parser used for stage two, bundled unmodified from its published source. AGPL-3.0.
• JSON Resume schema — the specification the test resume validates against.
• npm registry search API — the source of the 602-template population.
• Poppler pdftotext and pypdf — the two independent text extractors, whose disagreement surfaced the ligature finding.
• Chrome 80 deprecations — HTML Imports, the feature one template still depends on, removed from the browser.
• Our first study — where the claim that most resumes are rejected by software was traced to a vendor that closed in 2013 without publishing one.