We Ran Our 24 Templates Through Our Extraction Gate: Here Is the Exact Text the Robot Sees

Why 'the exact text the robot sees' is the right test

An applicant tracking system doesn't look at your resume; it extracts the text layer from your file and parses that. Everything a recruiter later searches or skims inside the ATS derives from that extraction. So the honest question about any template is not 'does it look clean?' but 'when this layout becomes a PDF, does the extracted text contain everything, in order, with the words intact?'

That framing gives you a test with three measurable properties:

• Completeness. Every word of the source resume should be recoverable from the PDF's text layer. Measured as token coverage: the share of expected tokens found in the extraction.
• Order. The name, summary, and section headings should appear in the extraction in the template's declared reading order. A layout that visually reads fine but extracts scrambled has failed its user silently.
• Integrity. Words should come out as words. Some typographic choices (notably aggressive letter-spacing) fragment extraction so 'SUMMARY' becomes six separate letters. We measured that failure starting at 0.11em of letter-spacing, so every template in the catalog is capped at 0.04em.

Methodology: reproducible from our codebase

The test is a script in our repository (scripts/check-template-parity.ts), not a marketing exercise, and it runs against the real production rendering pipeline rather than a simulation of it. For each of the 24 templates in the registry:

1. The same fixed sample resume is rendered through the template by our production print route, served by the same Next.js build users get, and converted to PDF by the same Chromium-based engine that produces every customer download
2. The text layer is extracted from the resulting PDF with unpdf, an extraction library built on the pdf.js engine, the same extraction approach ATS parsers depend on
3. The extraction is compared to the canonical text of the source resume (the resumeToText serialization), token by token: text is Unicode-normalized (NFKC, which also folds PDF ligatures like fi back into letters), lowercased, and split on non-alphanumeric characters
4. Coverage is computed as a multiset: every occurrence of every expected token must be found, so a word appearing three times in the source must appear three times in the extraction to count fully
5. Reading order is verified separately: the name, the summary heading, and every content-bearing section title must appear in the extraction in the template's declared reading sequence
6. The gate passes a template only if coverage exceeds 95 percent AND order is intact. Any failure fails the entire run, and the rendered PDFs are saved as artifacts for manual inspection

Results: every template, every number

Latest measured run: 2026-08-16, all 24 templates, two-page render of the sample resume in every case. Reading order was preserved in 24 of 24 templates. Token coverage by template:

What the gate caught while we built the catalog

A gate is only interesting if it has teeth, so here's what failed on the way to these numbers. The most instructive finding was typographic: classic serif templates traditionally use wide letter-spacing on uppercase names and section titles, and we found that PDF text extraction starts splitting such text into single-letter fragments at 0.11em of tracking. The failure is binary and sharp: below the threshold words extract whole, above it 'SUMMARY' extracts as separate letters that match no search. Every template in the catalog now clamps letter-spacing to at most 0.04em, and our Heritage family gets its traditional look from case, rules, and type choice instead of tracking.

That finding generalizes beyond our templates, and it's a thing almost no 'ATS-friendly' checklist mentions: if your current resume uses stylized spacing on headings, its extraction may be shattered in exactly this way regardless of how conservative the layout looks. It's also invisible to the eye, which is precisely why we show the extraction: the checker computes what share of your file's words read back as whole words, and puts the raw text in front of you.

The gate also enforces reading order per template, which constrains design in useful ways. Banner headers (Nova, Onyx), education-first orderings for students (Beacon, Primer), and monospace styling (Mono) all had to prove their extraction sequence before shipping. The rule is simple: a layout idea that can't keep name, summary, and section titles in declared order in the extracted stream doesn't ship with the badge, however good it looks.

The four templates we refuse to badge, honestly

Our four Statement-family templates (Studio, Panorama, Duet, Atlas) are two-column layouts, and in this very study they measured 98.94 percent token coverage with clean reading order. So why do they carry a 'Best for human review' label instead of ATS-Verified?

Because the test we can run on them is structurally weaker, and badge integrity matters more than badge count. For a single-column template, the gate verifies one property with real force: the entire resume is a single text flow, so there is exactly one reading order for any parser to find. For a two-column template, no such single sequence exists. Our gate verifies each column's internal order independently (header and main column; sidebar), and on multi-page renders pagination legitimately interleaves the two columns page by page. Different ATS parsers walk multi-column pages differently, and none of them publish how. We can prove our two-column extraction is internally coherent; we cannot promise every parser will reassemble the two lanes the way a human eye does. So the label says what we know: strongest when a person reads first.

When should you use them anyway? Referrals, career fairs, printed copies, portfolio-driven hiring: contexts where a human is the first reader and the visual lane for skills and credentials earns its keep. The Statement family page covers the trade-off, and every export falls back to a clean single column in DOCX and TXT so you're never locked into the two-column gamble for a portal submission.

Limitations: what this study cannot tell you

A study is only as trustworthy as its stated limits, so here are ours, unprompted.

One extraction engine. We extract with unpdf, one open-source implementation of PDF text extraction. Commercial ATS parsers use their own engines, and engines can disagree on tricky files. Our defense is that the templates are engineered to have no tricky parts: single text flows, real fonts, clamped spacing. The plainer the input, the less room engines have to disagree, and making the input plain is precisely what the gate enforces. Still, 'extracts perfectly in one engine' is evidence, not proof, for every engine.

One fixture. Every number in this study comes from one deliberately complete two-page sample resume. A different resume (very long URLs, unusual unicode, ten pages of roles) could surface different residuals. The fixture is designed to exercise every section type our builder supports, but it cannot exercise every resume that exists. This is why the checker matters: it runs the same extraction on your actual file, which is the only test that covers your actual content.

Parsing, not ranking. The gate measures whether text survives the trip into an ATS. It says nothing about how any employer's ranking, filtering, or recruiter searches will treat that text, which depends on your content and their configuration. A verified template gets your words into the database intact; it cannot make the words good.

A snapshot in time. These numbers describe the catalog as measured on August 16, 2026. Templates evolve, rendering engines update, and the gate re-runs on every change precisely because past results do not certify future builds. When the numbers change, this page changes.

How this compares to how templates are usually marketed

We researched the competitive landscape thoroughly while building this catalog, and the standard pattern in the resume-builder market is: describe every template as ATS-friendly, attach no test, publish no numbers. Sometimes the claim decorates layouts with dark sidebars, skill-rating bars, and two-column structures, precisely the features that make extraction unpredictable, with no distinction drawn for the buyer.

We're not going to claim competitors' templates fail parsing; we haven't measured them, and this study only asserts what we measured. What we will say is structural: a claim without a method isn't information, it's decoration. The useful questions to ask of any template vendor, ours included, are the ones this study answers in the open:

• What exactly was tested, on which rendering pipeline: the real one users export through, or a mockup?
• What was measured: token coverage against source content, reading order, both, neither?
• What threshold does a template have to clear, and what happens when one doesn't?
• Which templates carry the claim and which don't, and is the vendor willing to label some of its own catalog as NOT verified?
• Can the test be re-run, and are the artifacts inspectable?

What this means for your resume, whichever tool you use

You may never use our templates, and the study still gives you a working checklist, because the failure modes we gated against are universal:

• Verify extraction, don't assume it. The single most valuable habit from this entire study: look at your resume's extracted text before an application spree. Our free checker shows it in seconds, unlimited, no account.
• Treat letter-spacing as a hard risk. Stylized tracking on names and headings can shatter extraction invisibly. If your template spaces out its uppercase titles, check what the words look like in the extraction.
• Prefer one column for portal submissions. Not because two columns always fail, but because one column is the only layout whose reading order is provable in general.
• Expect long URLs to fray. Schemes and line-wrapped path fragments are the first casualties of extraction. If a link must be copy-pastable from the parsed record, keep it short and on one line.
• Judge badges by their method. Any 'ATS-approved' label without a published test is a font choice, not a fact. Ask the five questions above.

Frequently asked questions

Did you test against real ATS platforms like Workday or Greenhouse?

No, and we say so plainly: commercial ATS vendors don't expose their parsers for benchmarking, and any tool claiming to have scored your resume 'in Workday' should explain how. What we test is the layer every one of those systems depends on: the text extractable from the PDF. If extraction is complete, ordered, and intact, you've secured the input that all parsers share.

What does 98.94 percent coverage mean concretely?

The sample resume serializes to 284 expected tokens, counted with multiplicity. In a 98.94 percent run, 281 of 284 token occurrences were found in the PDF's extracted text; the 3 misses were the URL scheme 'https' (expected three times, displayed differently by the templates). All job titles, employers, dates, skills, and bullet content extracted completely.

Why do four compact templates score 98.24 percent instead of 98.94?

In Vector, Stacker, Primer, and Mono, the sample's long GitHub project URL wraps across a line break in a way that splits two of its path tokens during extraction, on top of the three scheme tokens missing everywhere. That's 5 of 284 tokens, all from one URL. Resume prose was unaffected, and all four templates clear the 95 percent gate with reading order intact.

Can I reproduce this study?

The gate is a script in our codebase (scripts/check-template-parity.ts) that renders every registry template through the production build, extracts each PDF's text with unpdf, and fails if any template drops below 95 percent coverage or breaks reading order. It saves all 24 PDFs as inspectable artifacts. Same input fixture, same tokenizer, same threshold on every run.

If the two-column templates scored 98.94 percent, why not badge them?

Because our test proves less for them. A single column has one provable reading order; two columns have two internally ordered lanes that different parsers may reassemble differently, and multi-page renders interleave the lanes page by page. We verify what's verifiable and label the rest honestly: Best for human review, with single-column DOCX and TXT fallbacks built in.

How do I check what a parser reads in my current resume?

Upload it to the free ATS checker. It extracts your file's text layer with the same approach used in this study and shows you the raw result, plus deterministic checks on extraction quality, contact details, section headings, and dates. Scans are unlimited and free, and files are processed in memory, never stored.