Why we test
Most employers run resumes through an applicant tracking system before a person reads them. The system's parser tries to fill a form: your name, email, phone, city, each job with its title, company and dates, each school and degree, your skills. If the layout confuses the parser, a field is wrong or empty, and the recruiter searching that database never sees it. So we test the layout itself, not just the words.
What we tested
- Every template. All 30 templates on offer today.
- Three sample people. Made-up but realistic: a software engineer in the US, a product manager in India and a fresher in India. Each has several jobs, schools and a skills list.
- The real file. Each PDF is made through the same Download PDF path you use in the editor, not a special test export.
- Commercial resume parsers. The PDFs were sent to commercial resume parsers of the kind hiring software uses. The 22 older templates were read by three parsers; the 8 newest by two so far. We don't name them.
- Our own checker. The same PDFs go through the checker behind our ATS check, on every build.
How: field by field
For each file we compare what the parser returned with the data that made the PDF, one field at a time: name, email, phone, city, LinkedIn, each job's title, company and dates, each school, each degree with its school, each listed skill, and whether the Experience, Education and Skills headings were recognised. We also count phantom jobs: entries the parser invented, such as a project read as a job.
What “pass” means
- A field is right only when it matches what the person typed: titles, companies and schools exactly (case and punctuation aside), and dates to the month.
- A job is right “whole” only when its title, company and dates land in one entry together.
- A school written with its city counts as right when the parser returns the school without the city, because parsers file the city separately.
- Skills are a floor: some parsers rename skills into their own list, so a skill can be read and still not match word for word.
What we found
On one-column templates, across the parsers' latest reads, the name and email were right on every file, and 94% to 97% of jobs were read whole. Schools and degrees score lower, mostly because of our sample data: an Indian “PGP” degree is not a name the parsers know. Where a parser misread a layout, we changed the layout: dates now sit under each job title, education leads with the degree, names are no longer letter-spaced or split into two styles, and headings use words parsers recognise.
Two-column templates are read well by the commercial parsers, but our own stricter checker does not always read the name and city from them. That is why every two-column template is labelled “For email” and every one-column template “For online applications”, and why the label comes from the layout, not from a list we type.
What runs on every build
Every one-column template, with each sample person, goes through our checker before any change ships. It must read the name first and whole, every job's dates, bullets as text, known headings, embedded fonts and body text of 9pt or more. If a change breaks that, the build fails and nothing goes live.
Limits: what we have not tested
- Not every parser. Each employer's system is its own, and none publish how they work. No test can promise a job.
- Not every resume. Three sample people, in English. Your own content, very long resumes or unusual sections may read differently.
- The 8 newest templates have been read by two commercial parsers, not three.
- After the fixes, not every file was read again by every parser: some results are a sample weighted to the files that had failed.
- Only our PDFs. Word files, scanned resumes and images are not part of it.
- There is no official “ATS compliant” standard or certificate, so we don't claim one.
Check your own
Our free ATS checker reads any PDF on your device, with no account, and shows what software read from it. For how parsers work in general, read how an ATS actually reads your resume.