PDF or DOCX for your résumé? What parsers actually do with each

If the posting doesn't specify, DOCX is the safer default — not because PDF is "bad," but because a DOCX stores your document's structure while a PDF stores ink positions that every parser has to reverse-engineer. Here is what that difference actually does to your résumé, and when a PDF is perfectly fine.

What's actually inside each format?

Open a DOCX file and you find a structured document: paragraphs are paragraphs, styled headings are marked as headings, a table knows it is a table. When a parser reads it, the reading order is written into the file itself — there is very little to guess.

A PDF is a different animal. It was designed to make a page look identical everywhere, and it does that by storing characters with coordinates: put "M" at position x=72, y=714. Unless the file carries accessibility tags — most résumé exports don't — nothing in it says "this is a heading" or "this line comes after that one." Reading order, paragraph boundaries, columns — a parser must reconstruct all of it from geometry.

That reconstruction usually works for simple layouts. But "usually works" is doing a lot of lifting in a process that decides whether your experience section lands under Experience.

Why does PDF parsing vary across systems?

Because guessing algorithms differ. One parser sorts text by vertical position and stitches lines; another clusters by distance; another uses the order objects were written into the file, which may not match the visual order at all. The same PDF can come out clean in one system and scrambled in another — the variance itself is the risk, and it is why any honest PDF analysis (including ours) is labeled an estimate.

A DOCX leaves far less room for interpretation, which is why its extraction is far more consistent across systems than PDF extraction.

When is a PDF fine?

To be fair to PDF: a text-based, single-column PDF with standard fonts — the kind you get from File → Export in Word or Google Docs — parses correctly in most modern systems. If your layout is already linear and clean, the format gap narrows to almost nothing.

PDF also has real advantages: your formatting is frozen (no font substitution on the reviewer's machine), and it reads identically on every device a human opens it on. If a human is the primary reader, PDF is often the better experience.

The PDF that fails by default: scans

There is one PDF variant with no redeeming qualities for applications: the image-only PDF. Scan a printed résumé, photograph it, or export from some design tools, and you get pages that contain a picture of text rather than text. A text parser opens it and finds zero embedded text; some systems fall back to OCR, which is slow, error-prone, and nothing to bet an application on.

Quick self-test: open your PDF and try to select a word with your cursor. If you cannot select a word, there is no text layer — anything a system gets from the file depends on OCR.

What if the posting requires PDF?

Then send a PDF — an explicit requirement always beats a general rule. Make it the good kind:

• Export, don't scan: File → Save As / Download as PDF from your editor, so the text layer is preserved.
• Keep the layout linear: single column, no tables for content, no icon fonts — the same rules as every other parsing risk.
• Check the extraction, not the look: the page rendering fools your eyes; the text layer is what machines actually read.

Compare both versions of your file

The cleanest way to settle the format question for your résumé is to stop debating in the abstract: export both formats and compare what a parser extracts from each. If both come out clean, submit whichever the posting prefers. If the PDF scrambles, you have your answer with evidence.