We Tested 13 Resume Templates Through Real ATS Parsers — Including Canva-Style Layouts

What we did: we rendered our own 8 resume PDF templates at run time from the exact code this product ships, sourced 5 additional, openly-licensed resume templates chosen for the same structural patterns common in Canva and Etsy templates (two-column layouts, graphical photo sidebars, icon-heavy designs), and ran all 13 through two independent PDF text-extraction engines — one of them the exact engine MyResumeKit's free ATS checker uses in production today. We are publishing every score — including the two of our own templates that scored worse than four of the five outside templates when we first ran this.

If you have ever wondered whether a good-looking resume template actually survives contact with an ATS, this is an attempt to answer that with a real, reproducible measurement instead of a guess. It found a genuine defect in two of our own paid templates, which we published before fixing and have now fixed; the before-and-after is in the results below rather than edited out.

Why We Ran This Study

Anyone researching resume formatting eventually runs into a version of the same worry: "I like this template, but will an ATS actually read it correctly?" It is a reasonable question, and most of the advice answering it is opinion dressed up as certainty — including, until now, some of our own. This site has told readers that multi-column layouts and graphical sidebars parse poorly. That claim deserved a real test rather than a repeated assertion.

So we built one. Not against a commercial ATS platform — those are proprietary, non-reproducible, and mostly gated behind paid trial accounts a reader could never verify independently. Instead we built a harness against two real, independent, open-source text-extraction engines, committed the harness to this site's repository, and published the raw results.

One limitation up front, not buried at the bottom: the five outside templates in this study are openly-licensed LaTeX templates hosted on GitHub, not the paid, drag-and-drop templates actually sold on Canva or Etsy. We wanted to test real commercial templates and ran into a real constraint — no reasonable way to acquire, measure, and republish findings about a paid, closed-license product without either violating its terms or leaving a reader unable to verify anything. Openly-licensed templates let us measure honestly and let any reader check our work. It also means you should not read "openly-licensed template X scored Y" as "the Canva template you're using scored Y" — see Limitations for the full reasoning.

What We Tested

Our own 8 templates — ClassicPDF, ModernPDF, MinimalPDF, ExecutivePDF, TechnicalPDF, CreativePDF, CompactPDF, and AcademicPDF — were rendered directly from the live @react-pdf/renderer components this product ships, using one fixed sample resume. They are never read from a stored file, so the study can never silently drift out of sync with what actually ships.

5 third-party templates, selected for structural variety and confirmed under an unambiguous open-source license before use:

Two of these five (oss-latex-sidebar-photo and oss-latex-infographic-icons) come from the same source repository, jankapunkt/latexcv, which publishes several distinct template designs — disclosed here rather than left implicit, since it means the third-party sample draws on 4 distinct authors, not 5.

None of the five source PDFs, .tex files, or any other third-party asset is redistributed in this article or committed to our repository — only our own factual description of each template's structure, our own screenshots of the rendered output, and the measured numbers.

Method

Two independent PDF text-extraction engines were used against all 13 templates:

• mupdf — the exact extraction path MyResumeKit's free ATS checker uses in production today, so these results describe what actually happens to a real uploaded resume, not a hypothetical.
• pdf-parse — a second, independent engine used only to cross-check mupdf. Where the two engines disagree, both numbers are published; neither is treated as the correct one.

Each (template, engine) pair produces a 0–100 overall score from four weighted sub-scores — Completeness, Action Verbs, Keyword Density, and Formatting — the same scoring pipeline the live product uses. Full field definitions are documented alongside the harness itself.

Reproduce it yourself:

npx tsx scripts/parse-test/run-study.ts

Run without flags, this reproduces our own 8-template results exactly — the harness makes no network calls, uses no AI model, and produces a byte-identical results file on every run against an unchanged codebase. An optional --input <directory> flag lets you point the same harness at your own set of resume PDFs (including, if you want to check this yourself, your own Canva or Etsy export) and measures them the same way, without ever committing or redistributing the files themselves.

Results: Our Own 8 Templates

The most useful thing this study did was fail. When we first ran the harness on 2026-08-02, AcademicPDF and TechnicalPDF scored 45 out of 100 on both extraction engines, with zero experience entries and zero education entries recovered by either one. Two of our own paid templates were materially worse at the one job this product exists to do, and we had been shipping them that way without knowing.

The cause was a letterSpacing: 1.5 style applied to section headings for visual effect. At that tracking, the rendered PDF gives each glyph enough horizontal advance that extractors recover "E X P E R I E N C E" instead of "EXPERIENCE" — enough to defeat the exact-text section-header matching the scoring pipeline relies on, so the experience and education sections were invisible to the parser even though the words were present in the file. Both independent engines agreed on the failure, which means it was a property of the PDF itself, not a quirk of one parser.

Fixed 2026-08-03. Reducing the tracking to 0.8 — the highest value we have measured evidence for, matching MinimalPDF, which extracts cleanly — recovered both templates to 86/86, with experience entries back to 3 and education back to 1, exactly matching the healthy templates. The other six templates' scores did not move at all. The fix is one style value per template; the monospace face on TechnicalPDF and the hairline rule on AcademicPDF were what carried those designs, so neither lost its identity.

We are leaving the original numbers in this article rather than replacing them with the clean ones, for two reasons. First, a study that quietly overwrites its own inconvenient result is not evidence of anything. Second, the before-and-after is the finding: it is the specific, reproducible demonstration that this measurement catches real defects in real shipping products — including ours. A regression test (tests/pdf-letterspacing.test.ts) now fails the build if any template's heading tracking goes back above 0.8, so this particular mistake cannot return silently.

If you exported an Academic or Technical resume from this site before 2026-08-03, that file has the wide heading tracking and may parse poorly. Rebuilding and re-exporting produces the corrected version.

The engine disagreement: MinimalPDF and CreativePDF scored 86 on mupdf but only 82 on pdf-parse. The cause is different from the Academic/Technical defect — pdf-parse merges the candidate's name and the contact-info line with no separating space, so the name field fails to recover cleanly, while mupdf preserves the line break and recovers it correctly. Neither engine is "wrong" here; it is a genuine difference in how two independent, widely-used libraries interpret the same PDF content stream, and it is a useful reminder on its own that no single extraction tool's score is the final word on how any resume will parse.

Results: Five Third-Party Templates

oss-latex-twocolumn-asymmetric (structure: a narrow sidebar column beside a wide main column) recovered name, email, phone, six experience entries, and two education entries cleanly on both engines — the best result of any third-party template, and proof that "two-column" alone does not doom a resume to parsing badly.

oss-latex-sidebar-photo (structure: a colored graphical sidebar holding a photo and contact icons, next to a main text column) lost the email address entirely on both engines — a real extraction failure, not an engine disagreement. The contact information lives inside the graphical sidebar block rather than the main text flow, which is exactly the kind of layout choice that puts information at risk during extraction.

oss-latex-classic-singlecolumn (structure: plain single-column, text-first) recovered every field cleanly on both engines but scored only 55–59 overall because of a very low Action Verbs sub-score. That sub-score reflects the specific candidate content in this particular public demonstration PDF — bullet points that do not open with action verbs — more than the template's structural design; see Limitations for why our own 8-template results and the third-party results are not directly comparable on content-driven sub-scores.

oss-latex-awesomecv-photo-header (structure: single-column body under a full-width graphical color header with a photo) lost the phone number on both engines, and both engines recovered zero experience entries despite the source content containing real work history — the graphical header block appears to disrupt reading order enough that the parser cannot locate the experience section that follows it.

oss-latex-infographic-icons (structure: icon- and progress-bar-heavy infographic layout) is the worst-scoring template measured anywhere in this study, own or third-party. mupdf failed to recover the email address at all (pdf-parse recovered it); neither engine recovered a single experience or education entry. Of every layout style tested, heavy reliance on icons and graphical progress bars in place of plain text was the most structurally hostile to clean extraction.

The Uncomfortable Part

Here is the comparison we are required to state plainly rather than soften. As first measured on 2026-08-02, our own AcademicPDF and TechnicalPDF templates scored 45/100 on both engines — worse than four of the five third-party templates, including two-column and graphical-header layouts. Only one third-party template, the icon-heavy oss-latex-infographic-icons (37/40), scored worse than our own worst two. For as long as those templates shipped that way, a paying customer choosing Academic or Technical got a worse-parsing resume than they would have got from a free LaTeX template off GitHub. That is the honest version of the sentence.

Both templates now measure 86/86 after the 2026-08-03 fix described above, so the current standing is that all eight of ours score 82–86 — higher than every third-party template we measured. We are not presenting that as the study's headline, because the number that tells you something about how this product is built is the 45, not the 86. Anyone can publish a table where they win. What the 45 shows is that the measurement is real enough to catch us, and that we ran it against ourselves and published the result before fixing it.

The narrower practical point still stands and is worth separating from our own case: the two structural patterns that hurt scores were consistent across our templates and the third-party ones — text inside graphical sidebars or icon blocks, and section headings styled so that exact-text matching breaks. Those are the things to check on any resume, from any builder.

What This Study Does and Does Not Tell You

These are open-source text-extraction engines, not commercial ATS platforms. mupdf and pdf-parse measure whether text extracts cleanly and in a sensible order from a PDF. They do not replicate any specific commercial ATS vendor's proprietary parsing or ranking logic. A template that extracts cleanly here may still be scored, ranked, or displayed differently by a real employer's ATS for reasons this test cannot measure — this study is a proxy for parsing fidelity, not a prediction of any named product's behavior.

The third-party sample is 5 openly-licensed templates chosen for structural variety, not a random or representative sample of what job seekers actually buy on Canva or Etsy. This is the direct trade-off of testing openly-licensed templates instead of paid, closed-license ones: these are free, GitHub-hosted LaTeX templates favored by a technically fluent audience, not the drag-and-drop templates sold to a non-technical audience on Canva or Etsy. Do not read "this open-source template scored X" as "the Canva bestseller you're using scored X" — only as "a template using this same structural pattern scored X."

Sample size is small: 8 of our own templates plus 5 third-party templates, 13 total. Two of the five third-party templates share a source repository (jankapunkt/latexcv), so the third-party leg draws on 4 distinct template authors, not 5.

Our own 8 templates use one fixed sample resume; the third-party templates each carry their original author's own real demonstration content, different names, different job histories, different lengths. That means a cross-template score comparison is measuring two different things — fixed content through varied structure for our own 8, and varied content through varied structure for the third-party 5. The Formatting and field-recovery sub-measurements are the most structure-attributable parts of each score for this reason; a low Action Verbs sub-score on a third-party template may reflect that author's writing more than the template's structure.

The third-party PDFs were LaTeX-rendered by their original authors; our own templates are rendered at run time by @react-pdf/renderer. Different rendering engines can produce PDFs with different internal text encoding even for visually similar layouts, and this study does not isolate that variable.

A template that extracts cleanly is not the only thing that matters. Keyword relevance, resume content quality, and a candidate's actual qualifications are entirely outside this study's scope.

How to Reproduce This

The full harness, both result files (own-templates.json and third-party-templates.json), and the methodology this article draws from are committed to this site's repository. Run npx tsx scripts/parse-test/run-study.ts to reproduce our own 8-template results exactly. The third-party results cannot be reproduced byte-for-byte without downloading the same five source PDFs yourself (we do not redistribute them), but the harness will measure any PDF, DOCX, or TXT resume you point it at via the --input flag — including your own resume, or a template you are considering.

What Actually Helps

None of this requires abandoning a template you like. What consistently hurt scores across both our own and the third-party set was specific, not stylistic: contact information or section content living inside a graphical sidebar or icon block instead of the main text flow, and section headings styled in a way that defeats exact-text matching. A single-column layout with standard headings and no embedded graphics is the safest default — it is also how MyResumeKit's own templates that scored 82–86 in this study are built. If you want to check where your current resume stands, MyResumeKit's free ATS checker runs the same underlying extraction path measured here, with no account required. For the honest version of the broader "does an ATS auto-reject resumes" question this study sits next to, see our debunk of that myth — and for a comparison of other free ATS checking tools, see our comparison post, which we have updated with these same measured numbers. If you're weighing a one-time PDF payment against a subscription resume builder, our pricing comparison covers that decision on its own terms.

Check your resume's ATS parse readiness for free or start building an ATS-tested resume →