Docling alternative: when you need resume fields, not text

Published 19 September 2026

If the documents you are parsing are CVs, and what you need out of them is fields — the employer, the job title, the month a role started, whether that role is still current — then Docling is the wrong shape for the job, and what you are looking for is a resume parsing API or a purpose-built parser. Docling's own one-line description is "Get your documents ready for gen AI". It is a document converter, and it is a very good one. What it hands back is a faithful, structured rendering of the page. Deciding that one line of that rendering is a company, another is a title, and a third is a start date, is a separate job — and that job lands on you.

That is the boundary of the tool rather than a fault in it. This article is about where that boundary actually falls, what the alternatives are, and the part most comparison pages skip: who should stay with Docling.

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

What Docling is, in its own words

Docling is an open-source document conversion library. Its README describes it as simplifying document processing "by parsing diverse formats", with "advanced PDF understanding" and a "unified, expressive DoclingDocument representation format":

Get your documents ready for gen AI

It was started by the AI for knowledge team at IBM Research Zurich and is now hosted as a project in the LF AI & Data Foundation. Its codebase is MIT licensed, with model licences tracked separately in the packages those models come from. You install it with pip install docling and run it inside your own process — Python 3.10 or higher — on macOS, Linux or Windows.

The input list is wide: PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, audio, email formats, LaTeX and more, all out to Markdown, HTML, DocTags, DocLang or lossless JSON. It advertises "extensive OCR support for scanned PDFs and images" and "local execution capabilities for sensitive data and air-gapped environments".

Notice which words are missing from that description. Nothing in it says resume, CV, candidate, employer or job title. Docling is a general-purpose converter, and every document type it lists is treated the same way.

The gap between a document and a candidate

A converter gives you the page. An applicant tracking system, a job board or a candidate-matching tool needs a person. The distance between those two is not one function call, and it is the same set of problems in every CV:

• Section detection. Nothing in a document model says "this heading starts the experience block". Headings arrive as EXPERIENCE, Work History, Professional Experience, or a bolded line with no colon at all.
• Column interleaving. PDF text extraction reads in stream order, so a sidebar of contact details lands inside the first job. This is the well-documented reason a naive parser puts a phone number in the middle of a job description.
• Date normalisation. 09/2016, Sept 2019, since January 2023, 2014 – 2018, Summer 2019. Anything you intend to sort or filter on has to become a comparable value first.
• Current roles. A role with no end date is not a role with a missing date — it is the job the person still has. In the document those read identically; in your database they must not.
• Documents that are not resumes. Someone will upload an invoice. A converter has no opinion about that and will convert it faithfully. Only a parser can tell you it was never a CV.

You can build all of this yourself. Plenty of teams do, and the next section covers when that is the right call. What it is not is a step Docling is going to take for you.

Docling vs a resume parsing API

Facts about Docling in this table are as of September 2026, read from its own pages.

Where Docling is the better answer

An alternative article that only argues for the alternative is an advertisement. Here is where Docling wins, and you should keep it.

• Your documents are not all CVs. Contracts, invoices, research papers, scanned forms. Docling handles the whole set with one pipeline; a resume endpoint will refuse every one of them, correctly.
• The data cannot leave your network. If your compliance position is that candidate CVs are never sent to a third party, a hosted API is not a candidate at any price. Docling's "local execution capabilities for sensitive data and air-gapped environments" is precisely this case.
• You want the document, not the fields. Search indexing, redaction, layout analysis, building a training set, feeding your own language model. Docling is built for exactly that, and it is a better tool for it than a resume endpoint, which throws away everything that is not a resume field.
• You want to own the extraction. If field extraction is your product rather than your plumbing, buying it is buying the part you exist to build.
• Your volume is small and irregular. A script run by hand on a few hundred CVs a month has no latency budget and no uptime requirement. Add a library, not a dependency.

Stay with Docling if any of those is your situation. The teams that should switch are the ones whose documents are overwhelmingly CVs and whose real work starts after the text is out — the job board that parses on upload, the ATS ingesting at volume, the matching tool that needs start_date to be sortable.

The other alternatives worth knowing

Within Docling's own category, the usual neighbours are PyMuPDF, pdfplumber, MarkItDown and unstructured. Each is typically faster on plain text extraction and narrower in what it understands, and every one of them still returns text or document structure rather than resume fields — so swapping between them does not change the gap described above.

If what you want is a purpose-built open-source resume parser, that landscape has its own article here: open source resume parser covers what each project actually returns and how much of it is still maintained, and Python resume parser has the code. The short version is that the projects that exist return a fixed field list from a stack you install and maintain yourself, and more than one has not shipped a release in years.

How to switch

A Docling step in a pipeline looks like this — and note where the work stops:

from docling.document_converter import DocumentConverter

doc = DocumentConverter().convert("cv.pdf").document
markdown = doc.export_to_markdown()
# ...and from here, the field extraction is yours to write

For the CV path specifically, replacing it is one request. The same document, sent to a parser that returns fields:

curl -X POST 'https://resumejson-resume-cv-parser-api.p.rapidapi.com/v1/parse' \
  -H 'x-rapidapi-key: YOUR_KEY' \
  -H 'x-rapidapi-host: resumejson-resume-cv-parser-api.p.rapidapi.com' \
  -F 'file=@cv.pdf'

{
  "resume": {
    "basics": { "full_name": "Sarah Okonkwo", "headline": "Staff Engineer", "email": "sarah@example.com", "phone": null },
    "work": [
      { "company": "Monzo", "title": "Staff Engineer",
        "start_date": "2022-03", "end_date": null, "is_current": true }
    ],
    "skills": [], "certifications": [], "languages": []
  },
  "meta": { "source": "pdf", "durationMs": 2212 }
}

The mapping layer you would have written is the part that disappeared. Three details in that response are the ones that cost the most to build:

• start_date is always YYYY-MM or YYYY — never "Summer 2019" — so roles sort and filter without a cleaning pass.
• A role with no end date comes back is_current: true, so a current job never reads as a job with missing dates.
• A field the CV does not state is null. No job titles inferred from a company name, no skills invented from a job description. A caller cannot tell an invented value from a read one, so a parser that guesses quietly poisons everything downstream.

It also runs inline rather than in a queue. Median parse is 2.2 seconds against the live endpoint, and every response carries an X-Parse-Ms header so you can see the time you are paying for on each call rather than trusting a number on a page. Scans and phone photos work too: a PDF with no text layer, or a JPEG of the page, is read as images instead, which takes a few seconds longer.

Which one to pick

• Keep Docling if your documents are mixed, your data cannot leave your network, or you need the document representation rather than the fields.
• Use both if you need CVs at volume and other documents too: Docling for the rest, a resume endpoint for the CV path, and no field-mapping code of your own to maintain.
• Switch if the CV path is the product and the extraction is plumbing you would rather not own.

You can see the output shape against your own CVs before deciding anything. The free parser runs one in your browser with no signup and no key, so the comparison is against your documents rather than against this page.