How we test our templates

What we check, with which tools, and where the checks stop. Everything here can be rerun by anyone.

Short answer

For every template we download the sample from Google Docs as a PDF, run it through the open-source OpenResume parser at a fixed version, and compare every field against what we wrote. We also check the raw text, the fonts and the Word export. We publish the results, including the parts the parser gets wrong. It isn't a score and it doesn't stand in for Workday or Greenhouse.

The latest run

Template	Fields matched (US Letter sample)	Pages
Jake's	46 of 46	1
Plain	33 of 33	1
Classic	38 of 38	1
Modern Accent	35 of 35	1
Compact	36 of 36	1
Student	35 of 35	1
Skills-first	33 of 33	1
International CV	63 of 63	2

Last run 2026-10-01. Every template's page shows the result for each file and paper size, field by field.

What we test

1. The export a real applicant makes

We don't make the PDFs ourselves. A script downloads each template from Google Docs through its public export address, which produces the same file as File > Download > PDF Document. No Google login is involved, so anyone can fetch the same file.

2. Field by field, with an open-source parser

We use the parser from OpenResume (AGPL-3.0), pinned to commit 4f8255a, with pdf.js 3.7.107. It's built for single-column English resumes, which is what our templates are. For each sample we wrote down, before running anything, what every field should contain: name, email, phone, location, link, summary, and for every job, school and project the title, organisation, dates and each bullet. Then we compare:

Each field and each bullet counts as one item.
Lists must match one to one, in order, with the same number of entries.
An empty expected field must stay empty, so text landing in the wrong field is caught.
Before comparing we ignore case, collapse spaces, treat all dash types as the same, and drop a leading bullet mark.

A template only goes live when every item matches.

3. The raw text

Using pdfminer.six 20260107 we extract the plain text and check that every line comes out in reading order, that no word is split in two, that no ligatures or private-use characters appear (these are what turn “fi” or a bullet into a box), and that no text exists outside the sections we expect. Cover letters and references pages get this check instead of field extraction.

4. Fonts, pages and the Word file

Every visible character must use the template's font, and every font must be embedded.
Each file must have the expected number of pages.
We download the .docx the same way and read it with python-docx 1.2.0: text in order, every bullet still a list item, and no bullet sitting on a symbol font.
We add one bullet to every job and lengthen the name to 30 characters, and the resume must still fit its page count. That's the room each template promises. Compact, which is already as tight as we'd go, is tested with the longer name only. Cover letters get an extra 60-word paragraph and references pages a fourth reference.

What the parser can't read

A test is only useful if you know its limits. These are the ones we found running OpenResume on our own samples:

Phone numbers outside the US format (+44 7700 900123, 07700 900123) aren't recognised as phone numbers. The text is still there.
Locations must look like “City, ST”. “London, UK” passes by luck; “Manchester, England” and “Berlin, Germany” don't.
Only one link is kept. If you list LinkedIn and GitHub, the second is in the text but not in the link field.
Short month names like Jan or Aug aren't recognised as months; the year carries the date. It still reads the date correctly in our layouts.
State codes that look like degrees. The degree rule matches capital pairs starting with A, B or M (BA, MS, MBA), so a school in “Boston, MA” can have its location read as the degree.
“High School” in a degree line counts against it being a degree.
Page breaks in multi-page resumes. The last line of one page is joined to the first line of the next. It's harmless when the break falls between two bullets, and breaks the entry when it falls between jobs. Our two-page CV is laid out so the break falls between bullets.

Names with accents, hyphens and apostrophes (José Álvarez, Mary-Jane Smith, Sean O'Brien) and Cyrillic names (Иван Петров) were read correctly in our tests. A Chinese name (王小明) was not: Google Docs draws it in a substituted Japanese font, and the parser left the name field empty, though everything else parsed and the page didn't move. The test files are in the repository under findings/. Where our own samples hit a limit, like the UK phone number on the International CV, the template page shows that field as outside the parser's rules and doesn't count it.

What we don't claim

We don't test commercial systems like Workday, iCIMS or Greenhouse. They don't offer a public way to test, and we won't imply any certification.
We test our sample text, not yours. Your own content can still trip a parser.
We don't give scores. A number out of 100 hides what actually went wrong.

Run it yourself

The test scripts, the expected values for every sample, the exact PDFs and .docx files we tested, and the raw results are in the test repository. With Docker installed:

git clone --recurse-submodules https://github.com/supertj/readableresume-parser-tests.git
cd readableresume-parser-tests
make docker-verify

It fetches each template from Google Docs, runs every check and writes one JSON report per file. Each report records the PDF's SHA-256, so you can confirm you tested the same file we did. The scripts are AGPL-3.0, like OpenResume.