How Resume Parsing Works, Stage by Stage
Every resume parser, open-source script or production API, runs the same five stages. Knowing them tells you exactly where parsing fails and what to test.
Resume parsing works in five stages: file ingestion, text extraction (with OCR for images), layout reconstruction, entity extraction, and normalization into a fixed schema. Each stage can fail independently; most “AI errors” are extraction or layout errors two stages earlier.
Stage 1 — File ingestion
The parser accepts the document and identifies what it is dealing with: a text-based PDF, a Word file, RTF, plain text, or an image. The distinction matters immediately: a text-based PDF carries its characters internally; a scanned PDF or a phone photo of a paper CV is just pixels. Production APIs accept both (SharpAPI takes PDF, DOC, DOCX, RTF, TXT, JPG, PNG and TIFF up to 100 MB) and route them differently from here.
Stage 2 — Text extraction and OCR
Digital documents give up their text directly. Images go through optical character recognition, which introduces its own error class: a fax-quality scan can turn “Java” into “Jaya” before any parsing logic runs. This is why OCR quality is part of parser quality, and why an endpoint with OCR built in beats stitching together two vendors and hoping the seams hold.
Stage 3 — Layout reconstruction
The stage most people have never heard of, responsible for a large share of real-world failures. PDF text arrives in stream order, not reading order. In a two-column resume, naive extraction interleaves the columns line by line: skills from the sidebar splice into the middle of a job description, and every downstream stage inherits the scramble.
Layout reconstruction detects columns, headers, footers and tables, and rebuilds the text into the order a human would read. Parsers that skip this stage are the reason career advisors still tell candidates to avoid two-column templates.
Stage 4 — Entity extraction
With clean, ordered text, the parser identifies what things are: which line is a name, which span is an employer, where a role starts and ends, which words are skills. Rule-based systems did this with patterns; statistical systems with NER models; current systems hand the reconstructed document to a large language model that reads it the way a human would, including the Portuguese CV and the resume whose employment section is titled “Where I've made an impact”.
Stage 5 — Normalization into the schema
Raw extractions become consistent data. Dates like “Jun '08 – present” become 2008-06-01 and null. A Polish magister and a UK MSc both normalize to a Master's-level degree_type. Skills attach to the position where they were used. Fields the document lacks return empty rather than disappearing. The result is a deterministic JSON contract that your code can rely on for every document — explore a real one here.
Why the stages matter to you
Because they are your debugging map and your evaluation checklist. Wrong characters point at stage 2: test with scans. Scrambled sections point at stage 3: test with two-column layouts. Misidentified fields point at stage 4: test with unusual section headings and non-English documents. Inconsistent dates or degrees point at stage 5: check the schema's normalization rules. A vendor's accuracy claim is a blend of all five; your document mix decides which stage dominates.
Questions, answered
How long does resume parsing take?
Seconds per document for a modern API. Because good endpoints run asynchronously — returning a status URL immediately — a thousand resumes take barely longer than one; the jobs run in parallel.
Does resume parsing work on scanned documents?
Only if the pipeline includes an OCR stage. Text-based PDFs skip OCR entirely; scans and photos need it. SharpAPI builds OCR into the same endpoint, so both document types go through one call.
Why do two-column resumes break some parsers?
Text extraction reads a PDF in stream order, which for two-column layouts interleaves unrelated lines. Parsers without a layout-reconstruction stage scramble the reading order and mis-assign content; layout-aware parsing solves it.
What model does modern resume parsing use?
Current parsers use large language models that read the reconstructed document and emit structured JSON directly, replacing the older pipeline of hand-written rules plus named-entity-recognition models. The gain shows most on unusual layouts and non-English documents.