How Does Resume Parsing Work? What a Parser Reads and Where It Fails

How does resume parsing work? A parser opens the CV file, pulls out the raw text, finds the sections such as experience and education, then tags the pieces it recognises as fields: name, contact details, job titles, employers, dates, schools and skills. It fails most on columns, tables, images and scans.

What resume parsing is for

A CV is written for a human reader. A person glances at the page, sees that the bold line at the top is a name, that the block under "Experience" is a list of jobs, and that "2019 to 2022" is a date range. A computer sees none of this. It receives a file and has to work out what every piece of text means before it can fill a candidate profile, search a database or compare a person with a job. Resume parsing is the step that does that work. Our page at /resume-parser gives the short version. This article goes deeper: what happens inside the parser, which fields it can reasonably be expected to get right, where it breaks, and how you can see the damage for yourself without any technical skill.

Why should a recruiter care? Because the parser sits at the very start of the pipeline. If it reads a job title as a company name, every later step inherits that mistake: the search misses the candidate, the profile looks wrong, and a score built on the parsed data is quietly off. Small and mid-size teams often discover this late, after weeks of working from profiles nobody checked. Understanding the mechanics lets you ask better questions of any tool, spot a bad parse in seconds, and tell candidates what to change when their file does not read well. Rules on automated processing of personal data differ by country, so treat the privacy points here as prompts to check local law.

How does resume parsing work, step by step

Almost every parser follows the same five stages, even though vendors describe them differently. Knowing the stages tells you where a given failure came from.

1. File intake. The parser accepts a PDF, a Word file or plain text. Some also accept images, but that adds a reading step covered below.

2. Text extraction. The parser pulls the characters out of the file. For a Word file or a text-based PDF this is usually clean. The order of the text is the hard part: the file stores text in the order it was written or drawn, not always in the order a person reads it.

3. Layout and section detection. The parser looks for headings such as Experience, Education, Skills and Summary, and splits the text into blocks. It uses cues like capital letters, bold weight, spacing and common wording.

4. Field tagging. Inside each block the parser identifies entities. A date pattern is a date. A line near a date that looks like an organisation is probably an employer. A phrase from a known list of skills is a skill. Modern parsers combine rules with trained language models, which helps with unusual wording but can still guess wrong.

5. Output. The result is structured data, often in a format developers can read, which then fills a profile or feeds a search or scoring step.

A failure in an early stage cannot be repaired later. If extraction scrambles the order of a two-column page, no amount of clever tagging can restore the original meaning. That is why layout, not intelligence, is the cause of most parsing errors.

What a parser reads: the fields

Parsers do not all extract the same fields, so ask any vendor for the exact list. The table below shows the fields most recruiters expect, how reliable they usually are on a plain single-column CV, and what tends to go wrong. The reliability notes are general observations, not measured figures, so confirm them with your own test.

Two things stand out. First, the fields that follow a fixed pattern, such as email addresses, are easy. Second, the fields that need context, such as which of two nearby lines is the title and which is the employer, are where parsers disagree with each other. If you take only one habit from this article, check titles, employers and dates on every parsed profile before relying on a search or score.

Where resume parsers fail

Failures cluster in a handful of layout situations. Most are visible to the naked eye once you know what to look for.

Two-column and sidebar layouts. The text may be read across the page instead of down each column, so a skills sidebar ends up spliced into the middle of a job description.

Tables. A CV built in a table can come out cell by cell, with dates separated from their jobs.

Text boxes, headers and footers. Contact details placed in the page header are sometimes ignored by the extraction step, which leaves a profile with no email.

Images and icons. A phone icon followed by a number is usually fine, but a name set as a graphic or a whole CV saved as one picture contains no text to extract.

Scanned PDFs. A scan is a photograph of a page. A parser needs an extra step called optical character recognition to turn it into text, and that step makes more mistakes, especially on small print or skewed pages.

Creative headings. A heading like "My journey" instead of "Experience" breaks the cue the parser uses to find the section.

Dates without months, mixed formats, or "present" written in another language. These produce wrong durations, which can make a candidate look junior or senior by mistake.

Non-English text and special characters. Names with accents, right-to-left scripts and unusual punctuation can be dropped or garbled, depending on the tool. This is worth testing directly if you hire across regions.

None of this makes a candidate worse. It only means the file is hard for a machine to read. Our guide at /blog/resume-parsing-errors-and-how-to-fix-them walks through fixes for each of these problems, and the test method in /blog/resume-parser-accuracy-how-to-test-with-ten-cvs shows how to measure them.

Rules versus language models: what is different

Older parsers were built on rules and word lists. They look for the heading "Experience", a date pattern and a list of known job titles. They are predictable, fast and easy to explain, and they fail when a CV does something unexpected. Newer parsers add language models that read the text more like a person, so they cope better with odd headings and sentences. The trade is that they can be confidently wrong. A rules-based parser tends to leave a field empty when it is unsure. A model-based parser may fill the field with a plausible guess.

For a recruiter this has a practical meaning. An empty field is easy to notice and fix. A wrong but plausible field is easy to miss. When you test any parser, look for both kinds of error, and ask the vendor how the tool signals low confidence. Also ask whether your candidate text is used to train models, and whether you can switch that off. Do not assume a model is better or worse than rules without testing on your own files. Vendors change their methods often, so check their current documentation rather than relying on anything written here about a specific product.

Worked example: one CV, two layouts

The numbers below are an example to show the effect of layout, not measured results from any product. Imagine one candidate, one set of facts, saved two ways: a plain single-column Word file and a designed two-column PDF with a skills sidebar and a header photo.

The candidate did nothing wrong in the second case. The facts are the same. A recruiter who searched for "operations coordinator" would find the first profile and could miss the second. This is why a parser's quality should be judged on the messy files your applicants really send and not on the clean sample files in a demo. It is also why it helps to let candidates upload in a format that reads well and to keep the original file next to the parsed profile, so a person can always look at the source.

How to check a parser yourself in an afternoon

You do not need a developer. Follow these steps.

1. Collect ten real CVs from a role you have already closed. Include a plain Word file, a two-column design, a table-based layout, a scanned PDF, a CV with a photo, one with non-English characters, and a short one-page CV.

2. Write down, for each, the five facts you care about: name, email, latest title, latest employer and total years of experience.

3. Upload them to the tool and compare each profile with the original file on screen.

4. Record every error and mark it as empty, wrong, or merged. Wrong is the most serious.

5. Run the same files a second day and see whether the result changes. Consistency matters as much as accuracy.

6. Ask whether you can correct a field by hand and whether corrections stick.

Score the results with the sheet below. The scoring is yours to adapt; it is a way to compare tools on equal terms.

A total below 8 out of 16 on your own files is a reason to keep looking, however good the demo was. The same method, with extra questions about ranking, is in our guide to /ai-resume-screening.

How to make a CV easier to parse

If you advise candidates or run an apply page, a few instructions reduce parsing errors for everyone. They are also the same advice a candidate would hear from a careers coach, so they do not require anyone to write for a machine.

• Use a single column with standard headings such as Experience, Education and Skills.
• Put contact details in the main body, not in the header or footer.
• Write dates as month and year, and use the same format throughout.
• Keep the file as a text-based PDF or a Word document, never a scan or a photo.
• Avoid text boxes, tables for layout, and graphics that carry words.
• Spell out the job title and the employer on separate lines or separated by a clear comma.
• Name the file with the candidate's name, not a long random string.

On your apply page, say these things in one short paragraph and offer a plain-text paste option for candidates whose file fails. Never reject someone for a parsing problem. If a profile looks empty or odd, open the original file and read it as a person would.

Privacy, bias and data handling

Parsing means the tool reads personal data: names, contact details, work history and sometimes dates of birth or photos. Before you adopt any parser, find out where files are stored, for how long, who at the vendor can see them, and whether you can delete a candidate completely on request. Ask whether the parser removes or hides details that you may not want to influence a first review, such as photos or dates of birth, if your local rules or policies call for it. Ask whether parsed data can be exported in full if you leave.

Parsing is also not neutral. A parser that handles one naming convention or one script better than another produces unequal profiles, and unequal profiles lead to unequal search results. This is another reason to include names and formats from the regions you hire in when you run your ten-CV test. Rules on automated processing and retention differ by country, so check local law, and write your findings into a short internal note so the next person to review the tool can see what was tested. Our guide at /blog/candidate-data-retention-policy-for-recruiters covers retention in more detail.

Common mistakes when relying on parsing

These are the errors that cost teams the most time.

• Trusting the demo. Vendors show clean files. Your applicants send everything.
• Never opening the original. If you only ever see the parsed profile, you cannot know what it left out.
• Searching on parsed titles alone. A title is often missing or wrong, so also search the full text.
• Treating an empty profile as a weak candidate. It usually means an unreadable file.
• Ignoring dates. A wrong duration changes how senior someone seems.
• Paying for features you will not use. Some tools charge more for fields you never look at.
• Forgetting to retest. A parser can change after an update, so repeat your ten-CV test once or twice a year.

Where Rezumz fits

Rezumz is an AI hiring workspace for small and mid-size hiring teams. It accepts CVs as PDF, DOCX or TXT, up to 60 at a time, scores each one against the job, and quotes the lines of the CV that support each match, so you can see what it relied on and check it against the original. People make every decision; Rezumz never rejects a candidate for you. It suits teams that screen many CVs and want a defensible shortlist.

It is not a standalone parsing service, and it does not promise perfect extraction on every layout, so run the ten-CV test above on your own files. It is also not a fit for large enterprises that need deep HRIS or payroll connections, or for teams that need one-click posting to job boards. Pricing: a free plan with 2 free candidate analyses; $29 a month, $199 a year, or $499 lifetime (limited); and Team at $79 a month or $699 a year for up to 10 teammates, suited to teams of 4 or more recruiters. See /pricing for current details and try the live demo at /demo.