Skip to content
ReadableResume

ATS resume parsing test: 10 layouts, 32 fonts

One sample resume, exported from Google Docs and read by an open-source resume parser. What changed the result, and what didn't.

By Super Lede. Last updated October 28, 2026. Raw data is free to reuse with credit.

Key findings

  • In two versions OpenResume read only 34 of 46 fields. In one, the name and contact details sat in a text box: Google Docs exported it as a picture, so they weren't in the PDF's text, and the parser took the heading “EDUCATION” for the name. In the other, the dates wrapped in a table column too narrow for them.
  • A photo, icons in the contact line, skill rating bars, contact details in the page header and dates in a table column cost nothing: OpenResume read all 46 fields in each, the same as in the plain one-column version.
  • In both two-column versions it read 42 of 46. It kept the columns apart; what it lost were lines that wrapped in the narrower column.
  • In a separate test of 32 fonts, 9 came through a Google Docs PDF export with all 46 fields read, and 16 stored letter pairs such as “fi” as a single character.

One sample resume with 46 fields, read by OpenResume at commit 4f8255a. Layouts tested October 28, 2026, fonts October 5, 2026.

Same resume, 10 layouts

We took the sample resume from our Jake's template and changed one thing at a time, keeping the words, the font and the sizes. Each version was imported into Google Docs, downloaded as a PDF and read by OpenResume, an open-source resume parser. Each square below is one of the 46 fields, always in the same order: contact details, then each job and its bullets, education, projects and skills.

Read correctlyMissed or wrong

  1. One column (control)

    46/46

    Nothing lost.

  2. Photo next to the name

    46/46

    Nothing lost.

  3. Icons instead of separators in the contact line

    46/46

    Nothing lost.

  4. Skill rating bars

    46/46

    Nothing lost.

  5. Name and contact details in the page header

    46/46

    Nothing lost.

  6. Dates in a table column on the left

    46/46

    Nothing lost.

  7. Dates in a table column too narrow for them

    34/46

    Lost 6 job titles, companies or dates and 6 education fields.

    Which fields
    • Job 1 company: read as 2025 (should be Ironhaw Freight)
    • Job 1 dates: read as May 2025 – Aug (should be May 2025 – Aug 2025)
    • Job 2 company: read as 2025 (should be Lakeshore State University)
    • Job 2 dates: read as Jan 2024 – May (should be Jan 2024 – May 2025)
    • Job 3 company: read as 2023 (should be Campus Technology Services)
    • Job 3 dates: read as Sep 2022 – Dec (should be Sep 2022 – Dec 2023)
    • Education school: nothing read (should be Lakeshore State University)
    • Education degree: nothing read (should be Bachelor of Science in Computer Science, Minor in Mathematics)
    • Education dates: read as Aug 2022 – May (should be Aug 2022 – May 2026)
    • Education GPA: nothing read (should be 3.7)
    • Education bullet 1: nothing read (should be GPA: 3.7/4.0, Dean's List six semesters)
    • Education bullet 2: nothing read (should be Relevant Coursework: Data Structures, Algorithms, Operating Systems, D…)
  8. Two columns built with a table

    42/46

    Lost 1 education field and 3 skills lines.

    Which fields
    • Education degree: read as Bachelor of Science in Computer (should be Bachelor of Science in Computer Science, Minor in Mathematics)
    • Skills line 1: read as Languages: Java, Python, Go, (should be Languages: Java, Python, Go, TypeScript, SQL, C)
    • Skills line 2: read as TypeScript, SQL, C (should be Frameworks: React, Node.js, Flask, JUnit, Pytest)
    • Skills line 3: read as Frameworks: React, Node.js, (should be Developer Tools: Git, Docker, AWS, PostgreSQL, Linux)
  9. Two columns built with Format > Columns

    42/46

    Lost 2 job titles, companies or dates, 1 education field and 1 skills line.

    Which fields
    • Job 2 company: read as 2025 (should be Lakeshore State University)
    • Job 2 dates: read as Jan 2024 – May (should be Jan 2024 – May 2025)
    • Education degree: read as Bachelor of Science in Computer Science, Minor in (should be Bachelor of Science in Computer Science, Minor in Mathematics)
    • Skills line 3: read as Developer Tools: Git, Docker, AWS, PostgreSQL, (should be Developer Tools: Git, Docker, AWS, PostgreSQL, Linux)
  10. Name and contact details in a text box

    34/46

    Lost 6 contact fields and 6 education fields.

    Which fields
    • Name: read as EDUCATION (should be Jordan Ellis)
    • Email: nothing read (should be jordan.ellis@example.com)
    • Phone: nothing read (should be (312) 555-0143)
    • Location: read as Chicago, IL (should stay empty)
    • Link: nothing read (should be linkedin.com/in/jordanellis)
    • Summary: read as Bachelor of Science in Computer Science, Minor in Mathematics Aug 2022… (should stay empty)
    • Education school: nothing read (should be Lakeshore State University)
    • Education degree: nothing read (should be Bachelor of Science in Computer Science, Minor in Mathematics)
    • Education dates: nothing read (should be Aug 2022 – May 2026)
    • Education GPA: nothing read (should be 3.7)
    • Education bullet 1: nothing read (should be GPA: 3.7/4.0, Dean's List six semesters)
    • Education bullet 2: nothing read (should be Relevant Coursework: Data Structures, Algorithms, Operating Systems, D…)

A text box turned into a picture

In the PDF, Google Docs drew the text box as an image. The name, phone number, email and both links were on the page but not in its text layer, so OpenResume couldn't read them. With nothing above the first heading, OpenResume took EDUCATION for the candidate's name, put the school's city in the location field and the rest of the education section in the summary, and found no education entry at all. 34 of 46 fields were right.

Two columns: the trouble was wrapping

We built one two-column version with a borderless table and one with Format > Columns. In both PDFs each column's text was stored in order, and the parser didn't mix the columns together. The losses came from lines that no longer fit. In the table version, the degree was cut after its first line, and the three skills lines, each wrapped, came back as six. In the Format > Columns version, one job's dates wrapped and the parser read the year on the second line as the company: 2025 instead of Lakeshore State University. In both versions it read 42 of 46 fields.

Dates in a table: fine until they wrapped

Putting each entry's dates in a table column on the left cost nothing when the column was wide enough. We then made the same column too narrow for the longest dates. They wrapped, and for every job the year on the second line was read as the company, and the education entry split in two. OpenResume read 34 of 46 fields.

What made no difference

With a photo, icons in the contact line, skill rating bars, contact details in the page header and dates in a table column, OpenResume read all 46 fields every time. The pictures sit beside the text and don't change it. Header text came out of the Google Docs PDF like any other line at the top of the page.

The .docx from the same documents

We also downloaded each Google Doc as a .docx. OpenResume reads PDFs only, so we didn't parse these; we looked at where the text sits in the file. In the page header version, the name and contact details are stored in the file's header part, outside the main body: 46 of the 51 pieces of sample text are in the body. In the text box version, the .docx still holds the contact details as text, inside the text box, even though the PDF of the same document turned them into a picture.

32 fonts

In an earlier test we changed only the font of the same resume, imported each version into Google Docs and downloaded it as a PDF. 9 of 32 came out with every character intact and all 46 fields read: Arial, Book Antiqua, Calibri, Cambria, EB Garamond, Garamond, Georgia, Times New Roman and Trebuchet MS.

  • 16 fonts stored a letter pair such as “fi” or “fl” as a single character. In 15 of them the parser also dropped the space before the word, reading “checks first” as checksfirst.
  • Google Docs drew Aptos, the default font in recent versions of Word, in Arial.
  • With Courier New the parser ran words together and read 10 of 46 fields.

The full table, font by font, is on our resume fonts page.

Names in other scripts

We replaced the sample name with an accented Latin name (José Álvarez), a Cyrillic name (Иван Петров) and a Chinese name (王小明) in two templates. The first two were read correctly. For the Chinese name, Google Docs drew the characters in a substituted Japanese font, and the parser left the name field empty in both templates. The email address was still read.

Where the 75% figure comes from

You will often read that 75% of resumes are rejected by an ATS before a person sees them. A Fortune career column from August 2014 said the number “probably came from a study by a job search services firm called Preptel” and gave no link or title for it. We looked for that study and didn't find it.

Our tests can't confirm or refute the figure. They measure what a parser takes out of a file, not what an employer does next, and a misread field is not a rejection. What they do show is that the misreads have causes you can see: in our tests they came from a text box, from lines that wrapped, from certain fonts and from a name in Chinese characters.

How we tested

  • Sample. The filled-in resume from our Jake's template, a fictional US computer science student. One page, US Letter, Times New Roman. In its own layout it reads 46 of 46 fields.
  • The 46 fields are the name, email, phone and link; location and summary, which should stay empty; the title, company and dates of each job; the school, degree, dates and GPA; the name and dates of each project; every bullet; and the three skills lines.
  • Each version was built as a .docx, imported into Google Docs in a private Drive folder, and exported through Drive as a PDF and as a .docx. Those are the same files File > Download gives you.
  • The parser is OpenResume (AGPL-3.0) at commit 4f8255a, with pdf.js 3.7.107. It's built for one-column English resumes. A field counts as read only if it matches what we wrote, after ignoring case, extra spaces and the type of dash. An empty field must stay empty.
  • pdfminer.six 20260107 checks whether each piece of text is in the PDF at all, which is how we know the text box became a picture.

These are the same parser and rules we run on every template on this site. How we test has the details.

Limits

  • One sample resume, one paper size and one export path. We didn't test Word's own Save as PDF.
  • One open-source parser. We didn't test Workday, Greenhouse, iCIMS or other hiring systems. They may handle text boxes, wrapped lines or letter pairs differently, for example by reading text from images.
  • A field the parser gets wrong is not the same as a rejected application.
  • Google Docs changes over time. The dates above are when the files were exported.

Data and how to rerun it

The data files are free to reuse under CC BY 4.0: credit ReadableResume and link to this page. The exact .docx and PDF files we tested, the field-by-field results and the scripts are in our test repository. With uv and Node installed:

git clone --recurse-submodules https://github.com/supertj/readableresume-parser-tests.git
cd readableresume-parser-tests
cd parser && npm ci && cd ..
make layout-study
make font-study

Each command rechecks the files in the repository and rewrites the results. To see what the same parser makes of your own resume, use the ATS resume checker. It runs in your browser and doesn't upload the file.

Cite this

Suggested citation:

ReadableResume (2026). ATS resume parsing test: 10 layouts, 32 fonts. By Super Lede. Updated October 28, 2026. https://readableresume.com/research/ats-parsing-test

In a sentence: “In a test by ReadableResume, Google Docs turned a text box holding a resume's contact details into a picture when exporting the PDF, and the open-source parser it used read none of them.” Please link to this page so readers can check the method.

Questions

Can an ATS read a two-column resume?
It depends on how the PDF stores the text and how the parser reads it. In our Google Docs PDFs, each column's text was stored in order and OpenResume kept the columns apart. Both two-column versions still lost 4 of 46 fields, all from lines that wrapped in the narrower column.
Can an ATS read text in a header or a text box?
Contact details in the page header read fine from the Google Docs PDF: 46 of 46 fields. A text box didn't: Google Docs exported it as a picture, and OpenResume missed the name, phone, email and links.
Do photos, icons or skill bars confuse an ATS?
Not in our test. OpenResume read all 46 fields in each version. They take up space, though, and space is what makes lines wrap.