DOCX vs PDF: which CV format parses best?

For a modern parser, the honest answer is that text-based PDF and DOCX both parse well, and the difference between them is small enough that candidates should not agonise over it. The formats that actually cause damage are scanned PDFs (which contain no text, only an image of text) and heavily designed CVs with columns, icons and graphics, in any file type. If you tell applicants one thing, tell them this: export to PDF from your word processor, keep the layout simple, and never upload a scan or a photo of paper.

What does a parser actually receive in each format?

The DOCX vs PDF debate makes more sense once you see what each file really is.

A DOCX file is structured XML in a zip archive. Paragraphs, headings, lists and tables are explicit elements in a defined order. A parser reading DOCX gets the document the way the author built it: this is a heading, this is a bullet list under it. That structure is a gift for extraction, which is why parsers historically loved Word files.

A PDF is a page description. It does not say “here is a paragraph”; it says “place these glyphs at these coordinates.” Reading order, columns and headings are not stored anywhere; the parser must reconstruct them from positions on the page. For a simple single-column CV that reconstruction is trivial and the result is as good as DOCX. For anything spatially clever, it is guesswork.

A scanned PDF is a third thing entirely: a container around a photograph. There are no glyphs to extract. Without an OCR step, the parser receives nothing at all, and with OCR it receives an approximation, with familiar failure modes: a 1 read as l in a phone number, an email mangled into something undeliverable, dates smeared across a fold in the paper. We cover the full extraction pipeline, including where OCR sits in it, in CV parsing explained.

So which one parses best?

Format	What the parser gets	Risk level	Notes
DOCX	Explicit structure (headings, lists, tables)	Low	Most forgiving; minor risk of odd templates and text boxes
Text-based PDF	Positioned text, structure inferred	Low	Equal to DOCX for single-column CVs; layout-sensitive
Scanned or photographed PDF	An image, text only via OCR	High	Names, emails and dates routinely corrupted; some parsers ingest nothing
Image files (JPG, PNG)	An image	High	Same OCR lottery, minus even the pretence of being a document
Exotic formats (Pages, ODT, HTML export)	Varies by parser	Medium	Support is inconsistent across systems

Two caveats on the low-risk rows. DOCX files built from heavily templated designs (text boxes, floating elements, content in headers) can scramble too, because the text lives outside the normal document flow. And a PDF exported from a design tool sometimes stores text as outlined shapes, which is functionally a scan. The format is a proxy; the real variable is whether the text is selectable and in a sensible order. The thirty-second test: select the text with a cursor and paste it into a blank document. If it comes out reading top to bottom like the CV, a parser will cope.

Why do two-column and graphical CVs scramble extraction?

Because PDF has no concept of reading order, a two-column CV forces the parser to choose: read straight across the page, or finish the left column before starting the right? Read across, and “Skills: Python” from the sidebar lands mid-sentence inside a job description from the main column. Read down, and a date that visually belongs to a role drifts to the wrong one. Either way the work history comes out subtly wrong, and subtle is worse than broken, because nobody notices until the inconsistency surfaces later.

Graphical CVs add their own failure modes. Skill levels drawn as star ratings or progress bars carry no text, so the information simply vanishes. Icons standing in for section headings (“a phone glyph instead of the word Phone”) strip the parser of its landmarks. Tables used for layout shred sentences into cells. The candidate spent hours making it beautiful; the parser receives confetti.

The newer generation of parsers narrows this gap. LLM-based extraction reads a CV more like a human does, using context to reassemble columns and infer which date belongs to which role, and it degrades gracefully where rule-based parsers fail; we dig into that shift in LLM resume parsing and structured data. But narrowing the gap is not closing it. A plain layout parses perfectly on every system; a designed one parses well on good systems and badly on the rest, and candidates rarely know which kind they are applying into.

What should you tell applicants?

Most candidates have absorbed years of contradictory folklore about “beating the ATS,” much of it written when parsers genuinely were terrible. Worth putting in your application instructions, your careers FAQ, or simply the help text next to the upload field:

• PDF or Word are both fine. Export the PDF from your word processor; do not scan or photograph a printed copy.
• One column beats two. Simple layout, standard section headings (Experience, Education, Skills), dates next to each role.
• Text beats graphics. Skill bars, icons and headshots add nothing a parser can read.
• Check the selectable-text test. If you can select and copy the text in order, you are safe.

This is also a candidate-experience point, not just a data-quality one. A CV that parses cleanly becomes a correct profile, which means correctly spelled names in outreach, accurate matching, and no “please retype your entire work history” form after the upload. The mechanics sit alongside everything else in how an ATS improves candidate experience.

What should your application form accept?

The opposite question matters just as much: candidates will ignore your advice, and the form should cope.

Accept PDF and DOCX as the baseline, and as many of DOC, RTF and ODT as your parser supports. Every rejected format is a candidate who may not come back with a converted file; plenty will just close the tab. Reject true image files (JPG, PNG) with a message asking for a document; accepting them silently produces empty profiles that look like ghost applicants. Set the size limit generously (10 MB covers any sane CV) because the most common oversized files are scans, and a size error nudges the candidate toward a proper export.

Then design for parser failure, because some files will fail no matter what. The wrong response is a blank profile or a mandatory retype-everything form. The right response is a profile created from whatever was extracted, flagged for a human glance, with the original file always attached and viewable. The parsed data feeds search and matching; the original stays the source of truth.

Where does Recruitifly fit?

Recruitifly’s parser is part of Fly, the one assistant that works across the whole platform. Hand Fly a CV, or a stack of them, and it parses each into a structured profile, then carries on with the work that follows: scoring and ranking against the job, building a shortlist, comparing the front-runners side by side. The division of labour matches what this post recommends: extraction runs as the mechanical step it is, while anything that touches a candidate (outreach, stage moves, interview bookings) arrives as a proposal you confirm. We consider that split the correct design, not a limitation.

We are in private beta. If you have a folder of awkward CVs (two columns, seven fonts, one suspicious scan), talk to us; messy real-world files make a better test than any clean sample deck.