We ran the same resume through 4 real ATS parsers in 36 layouts. Same text, different parses.

resumap.io — Tue, 28 Jul 2026 17:12:58 +0000

Every resume template on the internet is labelled "ATS-friendly". Almost nobody publishes what happens when you actually feed one to an ATS.

So we did the boring version of that experiment. One resume — same person, same three jobs, same fifteen bullet points, same skill list — exported through 36 different templates from the same PDF renderer, then imported into four production applicant tracking systems and diffed field by field.

The content never changed. Only the layout did. That turns out to matter more than it should.

The setup

The corpus is one synthetic candidate: a backend engineer, three positions, fifteen experience bullets, one degree, and a skill list containing ten job-critical skills. Every template renders exactly this content — the only variable is how the layout orders the text stream inside the PDF.

The four parsers:

Parser	What it is
Zoho Recruit	Full ATS, "Import from Document" parser
Manatal	AI-first ATS
Workable	Mid-market ATS, "Add candidate → Add resume"
Textkernel	Not an ATS — the OEM parsing engine documented behind SAP SuccessFactors and iCIMS

Textkernel is the interesting one. It's not a product job seekers ever see, but it's the engine under other people's ATSs, which means one parser's behaviour is inherited by a lot of enterprise hiring stacks.

Before blaming any parser, we extracted the text layer from every PDF locally and diffed it against the source data. Every defect described below is parser-side: the words were present, in the right order, in the file.

Result 1: nothing is uniformly "ATS-friendly"

Here's the same corpus across three of the four parsers.

Check	Zoho Recruit	Workable	Textkernel
Email parsed	36/36	36/36	36/36
Phone parsed	36/36	36/36	36/36
Location parsed	—	36/36	31/36
All 3 jobs segmented	34/36	36/36	31/36
Education clean	—	35/36	36/36
All primary skills kept	27/36	—	36/36

Look at the last two columns. Textkernel retained all ten job-critical skills from every single template, 36 out of 36 — the best skill extraction in the study. And the same parser dropped a location on five templates and mis-segmented work history on five. Workable was the mirror image: flawless on contact fields and job segmentation, 539 of 540 experience bullets recovered, but it mangled one degree glyph (M.Eng came out as N.Eng).

"ATS-friendly" is not one property. It's a per-parser, per-field property, and a layout that's perfect for one engine can lose a field on another.

Result 2: the same word disappears depending on layout

The most repeated defect in the whole study, across 36 templates of identical content, was this one on Zoho Recruit:

8x  primary skills missing: React

Eight templates lost React from the parsed skill list. Twenty-eight didn't. Same word, same skills section, same generator — different position in the text stream because the layout put it somewhere else on the page.

Zoho's overall picture, scored on a 22-check composite:

22/22  →  23 templates
21/22  →  10 templates
20/22  →   2 templates
18/22  →   1 template

Two thirds of the layouts parsed perfectly. The remaining third each lost one to four checks — and the losses were not random noise, they clustered on skills extraction (13 templates had at least one anomaly, 8 of them the React case).

Result 3: the hard thing was easy, the easy thing broke

This one genuinely surprised me.

Intuitively, pulling ten specific skills out of free text is the hard NLP problem, and figuring out "this block is job 1, that block is job 2" is bookkeeping. Textkernel inverted that: 10/10 primary skills on all 36 templates, with 54–69 distinct skills in structured output (median 68) — and then it merged or split work history on five of them.

Segmentation is where layout hurts, because segmentation depends on reading order, and reading order is exactly what a two-column or sidebar layout scrambles. Skill extraction is bag-of-words-ish and survives almost anything.

Result 4: two columns are not automatically fatal

The standard advice is "never use a two-column resume, the ATS can't read it". That's a decent heuristic aimed at a real failure mode, but it's the wrong diagnosis.

The failure mode isn't columns. It's text-stream order. A PDF has no concept of columns — it has a sequence of positioned text runs, and the parser reads that sequence. If the generator emits the sidebar interleaved with the main column, you get Skills Senior Backend React Engineer and the parse falls apart. If the generator emits the main column fully, then the sidebar, a two-column layout parses exactly like a one-column one.

Several of the two-column layouts in this corpus scored 22/22 on Zoho and 3/3 positions on Textkernel. Several one-column layouts didn't. The column count didn't predict the outcome; the emission order did.

Practical version for anyone generating PDFs: check what your text layer actually says, don't reason about what the page looks like.

# what the parser sees, not what you see
pdftotext -layout your-resume.pdf - | head -40

If that output reads like a resume, parsers will mostly cope. If it reads like two documents shuffled together, no amount of "ATS-friendly" branding saves it.

What I'd take away from this

Three things, in descending order of confidence.

Contact details are basically solved. Email and phone came back 36/36 on every parser we tested. Nobody is losing an interview because a parser couldn't find their email.

Skills and work-history segmentation are where layout actually bites, and they fail on different templates for different parsers, so there's no single layout that's optimal everywhere. Pick one that's boring in emission order and you're covering most of the field.

And the checkable claim beats the branded one. Any tool can print "ATS-friendly" on a template. It costs nothing and means nothing. What costs something is running the corpus and publishing what broke — including the five templates where our own output tripped a parser.

The data

We published all of it — the per-template results, the raw parser responses, the CSV exports and the PDF corpus itself, so anyone can re-run this against their own ATS:

Zoho Recruit round
Workable round
Textkernel round — the SuccessFactors / iCIMS engine
Manatal round — AI match scoring rather than parsing

Full disclosure: the 36 templates are the ones from Resumap, which I work on. That's also why the failure cases are in here — we found five templates of our own that a parser stumbled on, and the honest thing is to publish those alongside the wins rather than round them off.

If you've run a similar test against Greenhouse, Lever or Ashby, I'd genuinely like to see the numbers — those are the three we haven't been able to get trial access to.

DEV Community: resumap.io