The resume table problem: what 22,901 PDFs looked like to a parser

Tufan YAVAŞ — Mon, 21 Sep 2026 22:24:51 +0000

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.

How an ATS actually reads your developer resume PDF (and how to check it in two minutes)

Tufan YAVAŞ — Sun, 20 Sep 2026 21:23:51 +0000

Every few weeks someone posts a resume in r/EngineeringResumes that looks great and gets no callbacks. The usual advice is "quantify your impact". Sometimes the real answer is more boring: the tracking system never read the document properly.

Here is what happens to your PDF after you click Apply, and how to see it yourself.

Step 1: text extraction

The parser does not look at your resume. It extracts a character stream from the file, in whatever order the PDF stores it. For a single-column document written in a word processor that order matches reading order. For anything with columns, text boxes, tables or icons it often does not.

Common failure modes I see in developer resumes:

Two-column layout where the skills column is interleaved line by line with the experience column.
Dates right-aligned with a tab stop, which some parsers read as a separate paragraph.
Section headings rendered as icons (a wrench for Skills, a graduation cap for Education). The icon is an image; the parser sees no heading.
Skills as a bar chart. "Python ██████░░" extracts as "Python" and a row of box characters.
Contact details in the page header. Some parsers skip headers and footers entirely.

Step 2: section and field detection

From the character stream the parser guesses sections and then fields: job title, employer, start date, end date. It uses heading names and patterns. "Experience", "Work Experience", "Professional Experience" all work. "Where I made a dent" does not. Company on one line, title on the next, dates on a third is fine. Title and company on the same line separated by a pipe is usually fine. Dates in a separate column are the classic breaker.

Step 3: matching

Only now does keyword and skills matching happen, against the text the parser managed to structure. If your Kubernetes experience lives in a paragraph the parser assigned to the wrong job, it is still there for a human reader but may score as missing for the filter.

How to check your own file

Two options.

The manual one: open your PDF, press Ctrl+A, paste into a plain text editor. Read it top to bottom. If the order is wrong for you, it is wrong for the parser.

The faster one: upload the file to an ATS checker that shows the extracted text. I run one at OwlApply: ATS resume checker. It is free, needs no account, and returns the ATS score, the plain text a tracking system pulls from your file, and a list of what breaks parsing. Files are deleted after 24 hours. Content rewrite suggestions are part of the paid plan, but the parsing view, which is the part this post is about, is not.

What good looks like

If you want reference points, the 20 software engineer resume examples on the same site all pass the three steps above and cover full-stack, front-end, back-end, mobile, DevOps, QA, cloud and a few more. Each opens in the editor for free.

Disclosure: I am the founder of OwlApply (2024). The three-step description applies to every tracking system I have looked at, not just to our checker, so the Ctrl+A test is worth doing even if you never open our site.

DEV Community: Tufan YAVAŞ