What an ATS parser actually reads from your resume PDF: test results and an open method (2026)
The direct answer: a parser reads the text layer of a PDF, in the order it appears in the file's content stream -- nothing more. An image-only PDF has no text layer, so it reads as zero words, regardless of how good the resume looks on screen. Below is our own harness, run against our own exports, with the exact numbers it produced.
Results from our own harness
We built an open, reusable test harness (`scripts/ats-parse-study.mjs`, `npm run ats:study -- --self`) that extracts text from a PDF with pdfjs-dist -- the same library engine most real-world parsers are built on -- and runs it through the same four checks `scripts/ats-certify.mjs` runs before every release. Run on 2026-09-06 against our ATS-Friendly PDF export across five resume payloads (a typical one-page resume, a long eight-job career history, a minimal one-liner, a resume with accented/non-English characters, and a resume with no photo or social links), plus one control file: a raster-only PDF built with no text runs at all, the same class of export as our Designer PDF. Every row below is a real file committed to the repo at `ats-study/pdfs/self/` -- nothing here is estimated.
| File | Pages | Text layer | Words | Field recovery | Sections | Reading order | Keywords | Result |
|---|---|---|---|---|---|---|---|---|
| self/default-sample.pdf | 2 | Yes | 358 | Pass | Pass | Pass | Pass | PASS |
| self/image-only-control.pdf | 1 | No (image-only) | 0 | Fail | Fail | Fail | Fail | FAIL |
| self/long-resume.pdf | 2 | Yes | 438 | Pass | Pass | Pass | Pass | PASS |
| self/minimal.pdf | 1 | Yes | 18 | Pass | Pass | Pass | Pass | PASS |
| self/no-photo-no-socials.pdf | 2 | Yes | 356 | Pass | Pass | Pass | Pass | PASS |
| self/unicode-accented.pdf | 1 | Yes | 186 | Pass | Pass | Pass | Pass | PASS |
Why an image-only PDF reads as zero words
The `image-only-control.pdf` row above isn't a hypothetical -- it's a real PDF, built the same way, structurally, as our own Designer PDF: `src/utils/pdfExport.js` captures the rendered resume preview with html2canvas and embeds that snapshot as a single image on the page. That approach is deliberate and stays exactly pixel-perfect to what you see on screen -- same fonts, same layout, same spacing, matched exactly, every time. But a raster image has no text layer at all, so a parser extracts nothing from it: not your name, not a date, not one skill. That is exactly why the control file above fails all four checks and reads as 0 words.
This is also exactly why every download on YourCVMaker ships two PDFs, not one: the Designer PDF for a human reading it on screen or in print, and a separate ATS-Friendly PDF built from real, selectable text runs for the software that screens it first. Read exactly how we test that second file before every release.
The four checks, explained
Field recovery checks whether your name, email, phone, each job's company and title, and each school's name come back out of the extracted text as real, findable strings -- not lost, not garbled. Passing means the parser has something to map into its own structured fields; it doesn't prove any specific ATS will map them correctly, since that mapping logic is proprietary to each vendor.
Section detection checks whether standard headings -- Experience, Education, Skills, Projects, a professional summary -- appear in the extracted text at all. Passing means a parser looking for those headings has something to find; it doesn't prove a parser will group the right lines under the right heading.
Reading order checks that your name comes out before your experience and summary in the extracted text, instead of a multi-column or overlapping layout scrambling the order the file's content stream lists things in. Passing means the text comes out in a sane top-to-bottom sequence; it doesn't prove every line within a section stays in the order you wrote it.
Keyword retention checks that every skill you listed survives the round trip from PDF back to plain text, character-for-character. Passing means a keyword search against the extracted text would find it; it doesn't prove any particular ATS weights or ranks that keyword once found.
None of these four checks is a claim about a specific vendor's ATS software, and no test like this can be -- no company publishes exactly how their parser scores a resume, and anyone claiming otherwise is guessing. What these checks prove, narrowly and honestly, is that the file itself is built the way parsers document as safest to read.
Reproduce it, or add another builder
`scripts/ats-parse-study.mjs` isn't a one-off script -- it's a general-purpose harness that runs the same four checks against any folder of PDFs, given the resume that was supposed to produce each one. `ats-study/README.md` walks through adding a row for any other builder: type our published sample resume (`ats-study/expect.sample.json`) into that builder's free tier field-for-field, export the PDF, drop it in, and run the harness. No competitor row appears in this post today because we don't have a real competitor PDF on file yet -- we'd rather publish nothing than a guess. If you've exported a resume from another builder and are willing to share the PDF plus the exact resume content you typed into it, send it to us and we'll run it through the same unedited harness and publish the row, whatever it says.
Test your own PDF in the browser
Don't want to read a report -- want to check your own resume right now? Upload your PDF to our free ATS resume test and see, in plain terms, whether it has a real text layer and what a parser can actually recover from it.