We Ran 6 Popular Open-Source Resume Templates Through an ATS Parser. One Lost Every Digit.

Almost every resume guide tells you the same two things: never use two columns, and never let a parser see anything fancy. Both claims get repeated far more often than they get tested. So we took six open-source resume templates — the ones developers actually fork on GitHub — and pushed each one through the same PDF text extraction that runs when someone uploads a resume to this site.

The result contradicted the advice. Two columns parsed fine. Character encoding is what destroyed a resume.

What we tested, and how

Six PDFs, all from repositories with an explicit open-source licence. Text was extracted with the same library and the same call the site's uploader uses — not a better parser picked to make a point, because that measures the parser instead of the template. The extracted text then went through the same rule set behind our free ATS check.

Finding 1: one template loses every single digit

The Chinese edition of Deedy produced 1,709 characters of extracted text containing zero Arabic numerals. Not a low count — none. Every other file in the set returned between 69 and 453.

What that means in practice is that a parser reading this resume sees no graduation years, no employment dates, no metrics. The text comes out looking like this:

The numbers are visibly there when you open the PDF. They simply are not in the text layer, so anything reading the file programmatically never receives them. Every quantified achievement in that resume — the exact thing every guide tells you to add — is invisible to the machine.

Finding 2: the same file mangles its own Chinese characters

Sixty-nine characters in that same extraction are not the characters they appear to be. They are Kangxi radicals — a separate Unicode block that renders almost identically but is a different code point. The candidate's surname comes out as ⾼ (U+2F98, a radical) rather than 高 (U+9AD8, the character). 工程 comes out as ⼯程.

Finding 3: two columns did not break anything

This is the part that contradicts the standard advice. The English Deedy template is a narrow-left, wide-right two-column layout, and it passed every layout-related check: email extracted, phone extracted, contact details found in the opening lines, and zero lines flagged as scrambled column bleed.

The two-column warning is not baseless — columns implemented as untagged tables or text boxes genuinely do interleave when flattened to text. But a two-column layout is not automatically that. What we measured says the failure mode lives in how the file encodes text, not in how many columns you can see.

One result we threw out

The run initially flagged the zheyuye template for a missing phone number. It is not a defect. That template ships 13xxx-xxx-xxx as a deliberate placeholder in its sample content — there is no phone number to find. Reporting it as a template flaw would have meant counting someone's placeholder as a bug, so it is excluded from the conclusions.

We are mentioning a discarded result on purpose. A measurement you can only see the successful half of is not a measurement.

What to actually do about it

1. Open your own PDF and select the text with your cursor, then paste it somewhere plain. What lands in the clipboard is roughly what a parser receives.
2. Check the numbers specifically. Dates and metrics are the first things to disappear, and they are the hardest to notice missing.
3. If your characters or digits vanish, the fix is the font embedding, not the layout. Re-export with fonts fully embedded, or switch the export path entirely.
4. Do not rebuild a two-column resume into one column on the strength of the columns alone. Test it first — it may already be fine.

Reproducing this

The measurement script is in the repository as scripts/ats-template-audit.ts, and the source, licence and commit of every template is recorded alongside the files. Run it and you should get this table back. If you do not, this article is out of date and the script is right.