Yesterday I posted about the three steps a tracking system runs on a resume PDF: extract text, detect sections, match. Several people asked the obvious follow-up: how often does step one actually fail on real files?
We now have a number. Between May and September 2026, 22,901 PDF resumes went through the free checker I run, and since May the checker inspects the file itself (column geometry, tables, fonts, header and footer bands, images, glyphs), not only the extracted text. No individual resume is quoted below; everything is a count across the whole set, and the files are deleted after 24 hours.
The headline: only 5.8% of those PDFs had zero layout findings. 79.8% carried at least one major or critical finding. Here is what the findings were, and why the most common one is not the one everybody warns about.
The table is the real two-column problem
Every "ATS-friendly" guide says: avoid two columns. In the data, a real two-column or sidebar layout was flagged in 8.8% of files. Serious when it happens (the parser reads left to right across both columns and glues unrelated sections together), but rare.
Tables used for layout were flagged in 32.7% of files. Almost four times as often.
The reason is mundane. Most people do not build a two-column resume with real text columns. They open a word processor template, and the template is a borderless table: one cell for the sidebar, one for the main content, or a row per job with the dates in the right cell. On screen it is invisible. In the PDF it is a table, and a text extractor walks a table cell by cell, row by row.
Take a typical experience row:
| Senior Backend Engineer, Acme | Jan 2023 - present |
| Led migration of the billing service to event sourcing ... | |
Extracted, that becomes "Senior Backend Engineer, Acme Jan 2023 - present Led migration of the billing service..." if you are lucky, and "Senior Backend Engineer, Acme Led migration of the billing service... Jan 2023 - present" if the cells are emitted column-first. In the second case the date is now attached to the wrong block, and the section detector guesses a job with no dates. The human reader never sees a problem.
If you want to check whether your own file has this: open the PDF, select all, paste into a plain text editor. If your dates jump around or your bullets appear before the job title, you have a table.
The rest of the list
Share of the 22,901 PDFs that triggered each finding (a file can trigger several):
- Decorative bullets, icons or emoji: 48.9% (minor). They tokenise as unknown characters and can break section detection.
- Font risk (non-standard, not embedded, or under 9 pt): 46.0% (minor). Substituted fonts shift glyph widths; small text can fall under extraction thresholds.
- Non-standard section headings: 39.2% (major). Headings are matched against a list. "Professional Journey" can hide the whole experience block.
- Table used for layout: 32.7% (critical).
- Hyperlinks with hidden URLs: 32.5% (info). The target survives in the PDF; a printed or flattened copy loses it.
- Inconsistent or unsafe date formats: 31.4% (major). Parsers infer the pattern from the first date and can blank later entries.
- Contact details in the header or footer band: 22.1% (major). Many parsers only read the body layer.
- Images in the skills area (skill bars, rating dots): 16.3% (major). The image is stripped; the skill and its level are gone.
- Ligature or private-use glyphs: 11.5% (minor). "office" can come out as "oce".
- Two-column or sidebar layout: 8.8% (critical).
- Image-only file: 4.0% (critical). No text layer at all.
- Sub-readable hidden text under 4 pt: 1.4% (major). Keyword stuffing; recruiters who notice treat it as a red flag.
Two things stand out for developers specifically. The skill bar (16.3%) is a habit that comes from portfolio templates, and it deletes exactly the information a technical screen filters on. And the hidden-URL link (32.5%) is worth a second look: "GitHub" as a link text with the URL hidden is fine in a PDF viewer, but if the file is ever converted to text or printed, the reviewer has a word and no address. Print the URL.
What the clean 5.8% have in common
The files with zero layout findings were not fancy. Single column. Standard section names (Experience, Education, Skills, Projects). A system font at 10 to 12 pt. Plain round bullets. Contact details in the first lines of the body, not in the header. One date format throughout. That description covers the fix for roughly 80% of the findings above.
None of this requires a tool. If you already have a resume, the select-all-and-paste test takes a minute and catches the table problem, the header problem and the column problem. The checker adds the score, the extracted text and the list of findings for your specific file, without an account.
The full report, including the content findings (63.4% of resumes list a skill in the Skills section and never use it anywhere else), the score distribution and the methodology, is here: https://owlapply.com/en/blog/ats-resume-statistics
Disclosure: I am the founder of OwlApply, the checker these numbers come from. The parsing behaviour described here is common to the major tracking systems, not specific to our tool.
Top comments (0)