The Hardest Part of CV Analysis Isn't the AI — It's the PDF

People assume the hard part of building an AI CV analyser is the model: picking the right LLM, tuning prompts, fighting hallucination. That work matters — but in production, the bottleneck is usually earlier. PDF text extraction problems account for more silent failures than any scoring tweak. If you cannot turn a candidate's upload into faithful text, every downstream step — keyword matching, rewrites, scores — is built on sand.

A PDF is not a document

From a user's perspective, a CV PDF looks like a Word file frozen in place. Under the hood it is a page description language. Characters are positioned at coordinates; there is no native concept of "section" or "bullet list". When software parses a PDF résumé, it must reconstruct reading order from geometry. That inference is fragile.

Two-column templates are the classic failure. A human reads down the left column, then the right. Many extractors read left-to-right across the page, interleaving job titles from column A with dates from column B. The result is nonsense that still looks plausible enough to fool a quick glance — and completely wrecks automated analysis.

Failure modes we see every week

In the uploads we process, these patterns cause the most extraction pain:

• Multi-column layouts — skills on the right, experience on the left; parsers merge them incorrectly.
• Tables used for alignment — dates in one cell, bullets in another; structure is lost.
• Text in headers, footers, and text boxes — contact details vanish or duplicate.
• Icons and skill bars — "90% JavaScript" rendered as an image contributes nothing to text extraction.
• Embedded and subset fonts — ligatures and custom glyphs map to wrong Unicode code points.
• Scanned PDFs — a photograph of a printed CV requires OCR, with inevitable character errors.

None of this is the candidate's fault. Design tools optimise for human aesthetics, not machine readability. ATS vendors have dealt with these issues for years; AI analysers inherit the same mess.

Text layer vs scan

The first check on any upload is whether a text layer exists. A proper digital export from Word, Google Docs, or LaTeX includes selectable text. A scan — or a PDF printed to image — does not. For scans, we run OCR and attach a confidence score to each block.

OCR mistakes are insidious: "React" becomes "Heact", emails lose a character, dates read as "2O21". Keyword matchers then report false gaps; LLMs may "correct" text that was fine in the original. We surface low confidence extractions so users know to re-export rather than trust a broken parse.

Reconstructing reading order

When multiple extractors disagree, we do not blindly pick the longest string. Heuristics consider vertical position, font size (headings vs body), and repetition of date patterns. For stubborn layouts, we have experimented with vision models that read the page as an image — useful, but slower and costlier, which feeds into our speed vs depth trade-offs.

The goal is not perfect layout recreation. It is extracting text from a CV in an order that preserves employment chronology and bullet grouping. Good enough for analysis beats pixel-perfect for display.

Encoding, ligatures, and invisible characters

Less glamorous but equally painful: PDFs sometimes embed soft hyphens, zero-width spaces, or custom encodings where "fi" is a single glyph. Copy-paste from these files looks fine in a text editor but breaks exact matching. Normalisation passes collapse whitespace, strip control characters, and expand common ligatures before anything hits the LLM.

We also deduplicate contact blocks that appear in both the body and the margin — a frequent cause of double counting in skills sections.

Why extraction quality defines AI quality

A model cannot critique a bullet it never saw. Worse, it may confabulate content to fill gaps — the hallucination problem we tackle in building a CV analyser that does not hallucinate. Clean extraction narrows what the model is allowed to say; bad extraction forces it to guess.

That is why Cvaluate shows parsing-related issues early. If your dates scrambled, fixing the file beats tweaking keywords. Our PDF vs Word for ATS article covers what candidates should submit; this post is the engineering view of the same problem.

What you can do as a candidate

You do not need to understand PDF internals to protect yourself:

1. Prefer a single-column template with standard section headings.
2. Export PDF from an editor with a real text layer — avoid scanning.
3. Open the PDF, select all text, and paste into Notepad; if order looks wrong, parsers will struggle too.
4. Put contact details in the main body, not a decorative header.
5. Spell skills as text, not icons.

For the full picture of how parsing fits into modern hiring tech, see our guide to AI in hiring. To test your own file, run your CV through Cvaluate's free analysis — if extraction fails, you will know before recruiters' software misreads you.