Resume parser for recruiters: what to look for, and how to test one
Published
A resume parser reads a CV and returns its contents as labelled fields: name, email, phone, work history, education, skills. For a recruiter that means a candidate record fills itself in instead of being typed from a PDF. Most recruiters already use one without knowing it, because the applicant tracking system (ATS) runs a parser the moment a CV is uploaded. The real question is whether that parser is good enough for your CVs, and what to do when it is not.
This guide is for the recruiter or sourcer who works through CVs all day and wants to judge a parser without reading a spec sheet. It covers the three ways you end up with one, the fields worth checking, a short test you can run on your own files, and where a free tool is all you need. We build ResumeJSON, a parser aimed at developers, so read the parts about it as written by an interested party. Everything about our product was checked against the live site in October 2026.
The three ways a recruiter gets a parser
| Route | What it is | Best for | Watch out for |
|---|---|---|---|
| Built into your ATS | The parser that ships with the system you already use | Teams happy with their current records | You cannot swap it, and you rarely see what it got wrong |
| A standalone parser | A separate product or free web tool you feed CVs to | Cleaning up a folder, checking a few files, comparing parsers | One more place to copy results out of |
| A parser inside your own workflow | An API your developer connects to your forms, inbox or database | Agencies and job boards with a steady flow of CVs | Needs someone who can write the connection |
Start with the first. If the ATS parser fills your records correctly, you do not need another one. The rest of this page is for the case where it does not, or where you do not have an ATS at all and your CVs live in a shared drive and an inbox. Our guide to building a candidate database from CVs you already have covers that second situation in more depth.
The fields that decide whether a parser is useful
A parser that gets the name right and the work history wrong is worse than useless, because the record looks complete. These are the fields to check, in the order they hurt when wrong.
- Contact details. Email and phone are what you act on. A missing digit is an unreachable candidate.
- Job titles and companies. Search and filters depend on them. Check that a company name did not end up in the title field, and the reverse.
- Dates. Start and end of each role, and whether a current job is marked as current. Everything about seniority is computed from these.
- Education. Degree, institution and year, kept apart.
- Skills. A clean list, not a paragraph copied into one field.
- The empty case. When a CV does not state something, a good parser leaves the field empty. A parser that invents a value to fill the gap is the dangerous kind.
Our own parser follows that last rule: a field is null when the resume does not state it, never an empty string and never a guess. Whatever parser you pick, test for it.
A 20-CV test you can run in an afternoon
Vendor demos use clean CVs. Yours are not clean, so test on yours. This takes a short session and one spreadsheet.
- Pick 20 real CVs you have already read. Mix them on purpose: a few two-column designs, a few plain Word files, two scans or phone photos, one in another language, one unusually long career.
- Write down the right answer for five fields on each: email, current job title, current employer, most recent degree, and number of years worked. You already know these, so it takes a minute per file.
- Run every CV through the parser and paste the five fields next to your answers.
- Mark each cell right, wrong or empty. Keep "wrong" and "empty" apart. Wrong is the expensive one.
- Look at where the misses cluster. If every two-column CV fails, you have learned something the average score would have hidden.
A parser that is right on most of the 100 cells and empty rather than wrong on the rest is usable. One that is confidently wrong on a fifth of them is not, whatever its marketing says. This is also the honest way to compare two parsers: same 20 files, same five fields, no one's benchmark but your own. For the multilingual and scanned cases specifically, see how multilingual parsing breaks and how to test it and what to do when the CV is a scan.
When a free tool is all you need
If you parse a handful of CVs a week, or you are running the test above, you do not need a subscription or an integration. The free parser on our site takes a CV and shows the JSON on the same page.
| Free parser | What it does |
|---|---|
| Input | A PDF, a DOCX, a photo or scan of a printed page, or pasted text |
| Size | Files up to 8 MB, pasted text up to 20,000 characters |
| Account | None. No signup and no API key |
| Storage | The document is not stored |
| Language | Output in the CV's own language, or one you choose |
| Limit | One CV at a time, with a one-click check to keep scripts out |
Open the free parser and drop a file in. The result is JSON, which reads like a labelled list: you can see at a glance whether the email, employer and dates landed where they belong. It is meant for checking and one-off use. It is not a way to process a folder of 400 CVs, because you would be pasting 400 times.
When a recruiter needs more than the web page
The moment you want every incoming CV parsed automatically, you have left the web page behind. Two situations come up most:
- An agency with a steady inbox. CVs arrive by email, someone saves them, someone types them in. A developer, or a no-code builder, can connect a parser so the saved file becomes a row in your sheet or database.
- A job board or careers page. Candidates upload a CV and expect the form to fill itself. That needs a parser behind the upload. See job application autofill for how that works.
For these, our API takes one CV per request (PDF, DOCX, text or an image) and answers on the same request with the fields. As of October 2026 it is sold through RapidAPI at these plans, which are shown on our quickstart:
| Plan | Price | Included |
|---|---|---|
| Basic | $0 | 100 parses a month, a hard cap that cannot bill you |
| Pro | $0 | Pay per use at $0.05 a parse, no monthly fee |
| Ultra | $29 a month | 1,000 parses, then $0.045 a parse |
| Mega | $99 a month | 5,000 parses, then $0.018 a parse |
There is no batch endpoint: a folder of CVs means one call each, with the concurrency handled by whatever you build. If you are not the person who will write that, hand your developer our guide to bulk resume parsing and the automated screening page, which explains where parsing stops and rules begin.
When to stay with what you have
Be honest about whether you need any of this.
- Your ATS parser is accurate on your own 20-CV test. Stop here. Switching has a cost and you have no problem.
- You see fewer than a few dozen CVs a week. Typing the odd missing field is cheaper than any integration.
- Your trouble is the process, not the data entry. If the delay is in scheduling, feedback or sign-off, a parser changes nothing. Recruitment automation looks at which steps are worth automating first.
- You need a decision made for you. A parser reports what a CV says. It does not rank candidates or tell you who to hire, and it should not be asked to without a person reviewing the result, especially given how hiring law treats automated screening. Read our note on AI resume screening and the law before you build anything that scores people.
A short checklist before you choose
- Does it handle your worst CVs, such as scans and two-column layouts, and not only the clean ones?
- Does it leave a field empty when the CV is silent, instead of guessing?
- Can you see the raw result, so you can spot a wrong field yourself?
- What happens to the document afterwards? Ask whether it is stored.
- If you need volume later, is there an automatic route, and who builds it?
Run the 20-CV test on whichever you shortlist. Ten minutes of your own data tells you more than any comparison page, including this one.