Skip to content

Resumap Research · 2026-07-20 · study #3

We ran 36 resume templates through Workable's ATS parser. It read almost everything.

Third ATS in the series, same corpus: one fictional senior-engineer resume rendered in all 36 Resumap templates, imported into a real applicant tracking system and checked field by field against the source. Workable extracted every contact field, every work-history row with its dates, and 539 of 540 experience bullets. Two templates hit a single parser-side glitch each — both traceable to Workable's parser, not the resume. Here's the full breakdown, plus the corpus to re-run it.

36/36
templates where email, phone and location all parsed into the profile
36/36
templates where all three work-history entries parsed with their dates and durations
539/540
experience bullets extracted across all templates — one lost, to a parser glitch
36/36
candidates found by a skills-only keyword — every section is indexed for search even when a profile view doesn't display it

Every figure on this page is derived from a checked-in dataset; the corpus content is byte-identical to the Zoho and Manatal rounds.

Earlier in the series: the Zoho Recruit parsing test (which caught real template bugs) and the Manatal AI match-score test.

Methodology

  1. One fixture CV, 36 PDFs. The same fictional senior-engineer resume used across the whole series — three dated jobs with 15 bullets total, education, 25+ skills, projects — rendered by the production export pipeline in every enabled template. Only the contact email and phone digits differ per file (a numbered local part, no plus-addressing) to keep the ATS from merging duplicates.
  2. A matched job opening.A "Senior Software Developer" role whose requirements mirror the CV, created in the Workable trial so every candidate lands in one pipeline.
  3. Real import path. All 36PDFs added through Add candidate → Add resume — Workable's own resume parser (trial account, 2026-07-20). All 36 imported as separate candidates with no dedupe collisions.
  4. Field-level capture. Each candidate profile read directly from the Workable UI: contact block, profile header (current employer + education), the total-experience label, all three work-history entries with dates and computed durations, and every experience bullet — compared against the source resume.
  5. Full-text search probes. Tokens that appear in only one undisplayed section — one from the skills list ("Datadog") and one from projects ("ClickHouse"), each verified absent from every other section via a local PDF text-layer dump — plus a negative control ("Zanzibar", absent from every resume), run through recruiter search to test whether undisplayed content is still indexed.

How it parsed

Across 36 templates, Workable parsed the email, phone, location, current employer, education and total-experience label 36/36 times, and all three jobs with correct dates 36/36 times. It kept 539 of 540 experience bullets — a 99.8% capture rate on the densest part of the resume.

This is the cleanest parse of the three ATSs we've run — which is what we'd hope to see, since this corpus already carries the text-layer fixes the Zoho round surfaced. 34 of 36 templates parsed with zero defects. The remaining 2 each hit one small parser-side miss:

Boardroom

parser-side · not the template

parser dropped one experience bullet (source PDF text layer is correct)

Offset

parser-side · not the template

parser mis-read the degree glyph (M.Eng → N.Eng; source PDF text layer is correct)

Both misses are recorded against the parser, not the template: we extracted the text layer of each source PDF with the same tooling a parser uses and confirmed the dropped bullet and the "M.Eng" degree are present, verbatim, in the file. A different parser read them correctly. We publish them anyway.

The section you don't see is still searched

On the trial account we tested, the candidate profile displayed only Work Experience, Education and Contact — the Skills section wasn't rendered there. Yet a keyword that lives only in the skills list returned all 36 candidates in recruiter search (a projects-only keyword did too); a word in none of the resumes returned 0.

This is the difference between what a profile view shows and what search indexes. The profile card on this trial tier didn't surface a skills panel (paid Recruiting tiers do, along with a match score — neither was available to us here), so it's tempting to assume the skills section was ignored. It wasn't: the recruiter's keyword search reads the entire resume text. We proved it with a token that appears onlyin the skills list ("Datadog", confirmed absent from the experience, summary and projects): it surfaced every candidate. Keep your skills, tools and project detail in the document — a recruiter searching one of them will find you, even when a given profile view doesn't show the word.

One systemic normalisation worth knowing: Workable trimmed the title "Software Engineer, II–III" to "Software Engineer" on all 36 candidates — it strips the suffix after the comma. Harmless here, but a reason to put the search-relevant part of a title first.

The same templates, three real parsers

This is the third real ATS we've run the identical corpus through, and the pattern holds: Resumap's templates parse cleanly in production applicant tracking systems.

Zoho Recruit — before & after

The first pass caught real text-layer bugs in our templates (a lost job, a mangled email, dropped skills). We fixed them with no visual changes and re-ran — 16 templates parsing perfectly went to 23.

Manatal — parsed the fixed corpus

A second parser read the same (post-fix) content — every template extracted its jobs, dates, education and contact details cleanly.

Workable — near-perfect

This round: 36/36 on every contact field, work-history row and date, 539/540experience bullets, and two parser-side glitches that the templates weren't responsible for. The fixes we made after the Zoho round carry across parsers, because a clean top-to-bottom text layer is what every parser wants.

Textkernel — the enterprise engine

The OEM parser documented under SAP SuccessFactors and iCIMS. All 36 templates parsed with every job-critical skill retained and the richest structured skills list of the series.

Data & reproduction

Everything needed to verify or re-run this test. CC BY 4.0 — cite this page.

The corpus is the fictional Victor Lassoult persona — no real personal data. Same content as the Zoho and Manatal rounds.

Limitations — read before citing

  • One parser: Workable's resume parser, trial account, 2026-07-20. Other ATS products use different parsers; results don't transfer 1:1.
  • One fixture CV (senior software engineer, English, Latin script). Other professions, languages or scripts may parse differently.
  • This round measures parsing only, on the free trial tier. That tier's profile view showed Work Experience, Education and Contact but no Skills panel and no match score; paid Recruiting tiers do render a parsed Skills section and an AI match score. We couldn't measure either, so the skills finding here is about search indexing, not about whether Workable parses skills (it does) — and we describe the score only from what the vendor publicly declares.
  • Fields were read from the candidate-profile UI, one import per template. Parser behaviour may change as Workable updates it; the test date is part of the dataset.
  • Resumap runs this test on its own templates — an obvious interest. That's why the corpus and the scored results are downloadable: don't trust us, re-run it.

Questions this data answers

Did every resume template parse correctly in Workable?

Effectively yes. Across all 36 templates, Workable's parser extracted the email, phone, location, current employer, education and the "10 years" total-experience label every time, plus all three work-history entries with their dates and computed durations. Of 540 experience bullets it kept 539. Two templates hit a single parser-side glitch each (one dropped bullet, one degree-glyph misread) — and in both cases the source PDF's text layer is verbatim-correct, so the miss happened inside the parser, not the template.

Does a two-column or sidebar resume break Workable's parser?

No. Our corpus includes single-column, two-column and dark-sidebar layouts, and all of them parsed their contact block, full work history and education. The determinant isn't the number of columns on the page — it's whether the PDF's underlying text stream reads in a sensible order, which is what we fixed across the templates before this run.

Do the sections a resume parser doesn't display still get searched?

Yes — and it's a useful lesson for how you write a resume. On the free trial account we tested, the candidate profile rendered only Work Experience, Education and Contact — the Skills section wasn't shown there. (Paid Recruiting tiers do display a parsed Skills panel and a match score; those weren't on the trial.) But even where a section isn't displayed, recruiter search still indexes it: a token that appears ONLY in the skills list ("Datadog", which we confirmed is absent from every experience bullet, the summary and the projects) returned all 36 candidates; a Projects-only token ("ClickHouse") also returned 36; and a word in none of the resumes returned 0. Keep your skills, tools and project detail in the document — they're searchable even when a given profile view doesn't surface them.

Does this test cover the ATS match score too?

No — this study measures parsing only: whether the applicant tracking system reads your resume's fields correctly. Workable's match score is a paid-tier feature that wasn't on the free trial we used, so we didn't capture it. Parsing is the gate that matters first: if the ATS can't read your resume, no score helps you.

How does this compare to the Zoho and Manatal rounds?

Same corpus, three different parsers. Zoho Recruit caught real text-layer bugs in our templates on the first pass; we fixed them (no visual changes) and re-ran. Manatal then read the fixed content cleanly, and Workable read it near-perfectly here. Each ATS uses its own parser, so a clean parse in one doesn't guarantee a clean parse in another — which is why we keep running the same corpus through more of them and publishing each result.

Can I reproduce this test?

Yes. Download the corpus below, start a free Workable trial, create a job, and add the 36 PDFs via Add candidate → Add resume. Open each candidate profile and compare the parsed Work Experience, Education and Contact fields against the source resume. The scored results CSV lists what we observed per template.

Use a template that parses — then check your own resume

Every template in this test is free to use. And if you want to know how your existing resume reads against a specific job description, the ATS Check parses both and gives you an honest, itemised score.