Open source resume parser: what works, and when to buy instead

Published 16 September 2026

If you are looking for an open source resume parser that takes a PDF, DOCX or scanned CV and hands back typed fields — name, every role with dates, education, skills — the honest answer as of September 2026 is that no maintained project does that end to end. What open source gives you is excellent document extraction (text, layout, tables, OCR) and a schema to put the result in. The step in between — deciding that "Monzo — Staff Engineer, March 2022 to Present" is a company, a title, a start date of 2022-03 and a role that is still current — is the part you end up building and maintaining yourself.

That is not an argument against doing it. For plenty of teams it is the right call, and the last section of this article says who. But it is worth knowing before you budget a sprint for "we'll just use the open-source parser".

We build ResumeJSON, a paid resume parsing API, so read this as written by an interested party. Every claim below about another project was read from that project's own page in September 2026; those pages are theirs to change, so check anything you are about to depend on.

The open source resume parser options, compared

Facts in this table were read from each project's own page in September 2026.

pyresparser

pyresparser is the project most people find first, and the field list is the right one: name, email, mobile numbers, skills, total experience, college name, degree, designation and company names. It reads PDF and DOCX, with .doc support on Linux and macOS via textract.

The thing to check before you build on it is the release history. On PyPI, the latest version is 1.0.6, released 15 December 2019 — as of September 2026, that is nearly seven years without a release. Its own install instructions still ask you to fetch a spaCy model (en_core_web_sm) and NLTK word lists, and pinning a 2019 NLP stack against a current Python is where an afternoon goes. None of that makes it useless — it makes it a snapshot you are adopting rather than a library someone else is maintaining for you.

Docling

Docling is the strongest open-source piece of this puzzle and it is worth knowing about even if you buy the parsing step. It describes itself as simplifying document processing "by parsing diverse formats — including advanced PDF understanding". It takes PDF, DOCX, PPTX, XLSX, HTML, EPUB, images and more, exports Markdown, HTML and lossless JSON, and has "extensive OCR support for scanned PDFs and images". It understands page layout, reading order and table structure.

What it does not do is claim to give you a person's name, their skills or their employment history. It gives you a faithful, structured rendering of the document. For a CV that is genuinely useful — column interleaving is one of the two classic reasons a naive PDF extraction puts a phone number in the middle of a job description — but you still have to turn that rendering into fields.

OpenResume

OpenResume is an open-source resume builder that also ships a parser; its README describes the parser as a way for a user to "test and confirm its ATS readability", reading PDFs with PDF.js. That framing matters: it exists to check a resume, mostly one its own builder produced, rather than to ingest arbitrary CVs from strangers at volume. It is a good reference implementation to read if you want to understand how far you get from PDF.js alone.

JSON Resume

JSON Resume is a standard, not a parser: "The open-source initiative to create a JSON-based standard for resumes", with a CLI, a registry and themes. There is no import path on its site for turning an existing PDF or DOCX into that JSON. If you want the JSON Resume schema specifically, you will be mapping from whatever parser you use into it. (ResumeJSON's output is its own schema — basics, work, education, skills, certifications, languages — which is a similar shape but not the same field names, so treat it as a mapping job, not a drop-in.)

What building it yourself actually costs

The build-your-own route in 2026 is usually: extraction library for the bytes, then a language model for the fields. That gets a demo working in a day, which is exactly why teams underestimate it. The cost is in the cases after the demo:

• Two-column layouts. Text extraction reads in stream order, so a sidebar of contact details is interleaved into the first job. You either parse for meaning rather than position, or you write layout heuristics per template.
• Scans and photos. A CV emailed as a phone photo has no text layer at all. That is a different pipeline — OCR or a vision model — not a flag on the first one.
• Dates. 09/2016, Sept 2019, since January 2023, 2014 – 2018. If you want to sort or filter roles, every one of those has to become a comparable value, and "Summer 2019" has to become something your database will accept.
• Not-a-resume. Someone will upload an invoice. A parser with no opinion returns an object with every field empty, which downstream looks like a candidate with no history rather than a bad upload.
• Invented values. This is the one that costs you later. A model asked to fill a schema will happily infer a country from an area code or a job title from a company name. A caller cannot tell an invented value from a read one, so a parser that guesses quietly poisons whatever you do with the data.
• Maintenance. Model versions move, PDF libraries change, and an accuracy regression on CVs is invisible until a customer reports it. Somebody owns a test corpus now.

None of these are hard problems individually. Together they are a small product, and it is a product that is not the thing you are building.

Who should stay with open source

Genuinely, and not as a courtesy:

• You have a hard data-residency or on-prem requirement. If CVs cannot leave your infrastructure, a hosted API is not a candidate at any price. Docling plus your own model, self-hosted, is the answer.
• Your volume is small and bursty. A few hundred CVs a year, parsed by an internal tool, is not worth a vendor relationship.
• Parsing is the product. If you are building a resume parser to sell, buying one is buying your own competitor's output.
• You want the exact JSON Resume schema and are willing to map into it — the standard is open and stable, and there is tooling around it.
• You have ML capability in-house and a corpus. The moment you can measure accuracy on your own documents, a tuned in-house pipeline can beat a general one on your particular population of CVs.

If none of those describe you, the arithmetic usually favours buying, because the thing you are buying is not the extraction — it is the field decisions and the maintenance of them.

When a parsing API is the cheaper answer

ResumeJSON is a parse-only API: one POST /v1/parse, a typed JSON resume back, nothing else. Concretely, against the open-source gaps above:

• PDF, DOCX, plain text, and scans. The file type is detected from the bytes rather than from a header a browser guessed, and a PDF with no text layer — or a JPEG, PNG or WebP of the page — is read as images instead.
• Dates you can sort by. start_date is always YYYY-MM or YYYY, and a role with no end date comes back is_current: true rather than as a job with missing dates.
• It does not invent. A field the CV does not state comes back null. A document that is not a resume returns 422 not_a_resume rather than an empty resume object.
• Fast enough to run inline. Median 2.2 seconds measured against the live endpoint, so you can parse on upload instead of queueing a job.
• Any language in, and optionally out — an Indonesian CV returns Indonesian job titles, with only the dates normalised.

Pricing is on RapidAPI, with a free tier of 100 parses a month for testing against your own CVs, pay-per-use above it, and volume plans from $29/month. The enterprise end of this market — vendors like DaXtra, whose site as of September 2026 sells to "ATS and CRM vendors" and job boards and publishes no prices at all, quoting instead — is a different purchase with a sales cycle attached; we wrote up what one of those vendors publishes separately.

The honest test is not open source versus paid. It is whether the field decisions above are work you want to own. If they are, the open-source stack is better than it has ever been and Docling is where to start. If they are not, parse a few of your own CVs free, with no signup, and compare the output against whatever you were going to build.