Resume Parser Accuracy: How to Test a Parser With Ten CVs

To test resume parser accuracy, pick ten varied CVs, write down the correct value for each field by hand, run them through the parser, and mark every field as correct, partly correct, wrong or missing. Add up the results per field, not as one overall number, then read the failures to decide whether the errors would hurt your hiring.

What a resume parser does and why accuracy is hard

A resume parser reads a CV file and turns it into structured fields: name, contact details, job titles, employers, dates, skills, education and sometimes a summary. Those fields feed search, ranking and your candidate records. If the parser gets them wrong, every later step inherits the mistake. A candidate with an invented job title, or a missing employer, can be ranked low or never found in a search. Accuracy is hard because CVs have no standard. People use columns, tables, text boxes, icons, unusual headings, several languages and photos. Some CVs are scanned images, and some are exported from design tools in a way that scrambles the reading order. A parser that works well on neat single-column documents can fail on the creative ones, and the vendor demo will always use the neat ones. This is why a small test of your own is worth more than any accuracy figure on a website. For what parsing is and how it fits into a hiring workflow, see /resume-parser. The method below takes about two hours for one parser and needs no technical skills, only careful reading.

Step 1: choose your ten CVs

Choose CVs from your real pipeline, with names and personal details handled according to your privacy rules. If you cannot use real ones, ask colleagues for consented samples. A good set of ten covers the range you actually receive. Include: two clean single-column CVs in a word processor format; two with two columns or a sidebar; one with tables for skills or dates; one scanned or photographed document; one designed in a graphic tool and exported to a PDF; one in a language other than English if you hire in more than one; one with a career gap or overlapping jobs; and one very long CV of more than three pages. If you receive a certain file type often, such as a plain text or web page export, include one. Keep the original files and note the format of each. Do not clean up the files first. The point is to see how the parser behaves on what real people send. Record a short label for each CV so you can refer to them in your sheet without using names. Ten is enough to spot patterns and too few to claim a precise percentage, so treat the result as a screening test and not as a benchmark.

Step 2: write the answer key by hand

Before you run any parser, open each CV and write down the correct value for each field you care about. This is your answer key, and it must be made first so the parser's output cannot influence you. Suggested fields: full name, email, phone, location, current or latest job title, current or latest employer, start and end dates of the last three jobs, the total years of experience, each skill listed, highest qualification, institution and graduation year. For dates, decide the rule beforehand, for example that the month and year must both match, and what to do with the word present. For skills, list the skills that appear in the text, not the ones you assume. For total experience, write down how you calculated it. This step is the slowest, perhaps ten minutes per CV, but it is the foundation. If you skip it you will tend to accept plausible output as correct. A second person checking the key on two or three CVs catches your own slips, which matter because an error in the key looks like a parser failure.

Step 3: run each CV and mark every field

Upload or send each CV to the parser under test using its normal route, with default settings. Save the output, or take screenshots if it only shows on screen. Then mark each field against your key using four marks. Correct: the value matches your key. Partly correct: the value is right but incomplete or in the wrong format, such as a title without its seniority word or a date missing the month. Wrong: the value is present but incorrect, such as the wrong employer or a swapped start and end date. Missing: the field is empty although the CV contained it. Also note whether the parser warned you when it was unsure, because a visible warning is much better than a confident wrong answer. Mark all ten CVs for one parser before you start the next, and use the same people and the same rules every time. If you compare two parsers, run the same files in both and keep the answer key unchanged. Note the time each run took and whether any file failed outright, since a file that fails to load is the worst outcome of all if nobody notices.

A scoring table per field

Build a table with one row per field and columns for Correct, Partly, Wrong, Missing across the ten CVs, so each row sums to ten. Here is an example only, not a real result.

Give each Correct one point, each Partly half a point and the others zero, then divide by ten to get a per-field score. In this example, dates score 6 out of 10 and name scores 10 out of 10. Do not average everything into one number, because a parser can look good overall while failing on the fields you rely on most. Decide in advance which fields are critical for you, for example dates and job titles if you rank on experience.

Common failure cases to look for

The common failures, what they look like and why they matter are in the table.

Note which of these appear in your results, because each has a different business impact.

How to read the results

Look at errors by their consequences, not by their count. A wrong phone number is a nuisance you will catch when you try to call. A wrong employer or date may silently change a ranking and never be noticed. A missing CV that failed to load can mean a candidate is never seen. Rank each failure as low, medium or high impact for your process. Then ask how the parser behaves when it fails: does it flag low confidence, does it let a person correct the field, and does the correction stick? A parser that makes more errors but makes them visible and fixable can be safer than one with fewer errors that hides them. Also check consistency by running the same CV twice. Consider the parser in context with the rest of your workflow: if a person reads the CV before any decision, the parser is an assistant that saves typing. If the parsed fields drive automatic filtering, the cost of an error is much higher, and you should set a stricter bar. Whatever the numbers, no parser should be the only reason a candidate is excluded.

Worked example with example numbers

These numbers are examples only. A recruiter at a small agency tests two parsers on ten CVs. Parser X scores 10 out of 10 on name and email, 8 on job title and employer, but only 5.5 on dates, and it silently skips the scanned CV. Parser Y scores 9 on name and email, 7 on job title and employer, 7.5 on dates, reads the scanned CV with two character errors, and flags three fields as low confidence. The agency cares most about dates, because it ranks on years in role. By plain average, Parser X looks better. By the fields that matter, and the way failures are shown, Parser Y wins. The recruiter also notes that both parsers failed on the design-tool PDF, so the agency decides to ask candidates for a plain version when a CV does not parse. The takeaway is that the right choice depended on which fields matter and whether errors are visible, not on a headline accuracy figure. The recruiter writes the result into a one-page note with the date, the parser version if shown, and the ten file labels, so the test can be repeated later after an update.

Build versus buy

The options compare as follows.

A fair rule: buy or use built-in parsing unless you have a document type or a legal requirement that off-the-shelf tools cannot meet, and put a person in the loop for any field that drives a decision. Rules on handling candidate data differ by country, so check local law whichever route you choose.

Where Rezumz fits

Rezumz reads CVs as part of its hiring workspace, then scores each one against the must-haves you set and shows the lines it relied on, so a person can see whether the CV was read properly. CVs can come in through the apply page, upload, CSV import or email forwarding. It is built for small and mid-size hiring teams, with the Team plan aimed at teams of four or more recruiters. It is not a standalone parsing service for large volumes sent to other systems, it does not do one-click multiposting to job boards, and it is not a fit for large enterprises needing deep HRIS or payroll links. Prices: a free plan with 2 free candidate analyses, $29 a month, $199 a year, or a limited $499 lifetime option. Team is $79 a month or $699 a year for up to 10 teammates. Run the ten-CV test from this article on the live demo at /demo, and see /pricing for current details. Check any competitor's current pricing and features on their own site.

When this test is not for you, and next steps

A ten-CV test is not a formal benchmark. If you process thousands of CVs a week, you will need a larger sample, ideally a few hundred with an answer key, and perhaps technical help. If you never rely on parsed fields because you read every CV, the stakes are lower and a quick look at three or four files may be enough. If your CVs are mostly one language and one layout, you can shrink the test, but keep at least one scanned file. After the test, keep your answer key and the ten files, so you can rerun them whenever the tool changes or when you compare a new vendor. Pair this with the screening guide at /ai-resume-screening and the software overview at /recruitment-software. If you want a free way to hold candidates while you decide, see /free-applicant-tracking-system. Remember that parsing handles personal data, so know where files are stored, how long they are kept and who can see them, and check the rules where you hire.