GROBID: PDF to TEI XML for Scholarly Documents, and What It Costs to Run
A machine learning software for extracting information from scholarly documents
At a glance
- What is it?
- GROBID parses scholarly PDFs into structured TEI XML using CRF and deep learning models. The repository documents strong reference parsing scores and a Java 21 build path, but the deep learning stack adds a Python and JEP dependency that changes how you deploy it.
- Who is it for?
- GROBID fits teams that need structured TEI XML from scholarly PDFs at scale and can absorb a Java 21 service plus an optional Python 3.10-3.11 JEP environment for deep learning models. It is the wrong tool if you only need plain text, or if your corpus is not technical and scientific literature.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem GROBID solves: turning PDFs into structured TEI XML
Scholarly PDFs are a hostile input format. A journal article carries a title, authors with affiliations, an abstract, section headings, figure captions, footnotes, and a reference list where each entry has its own internal structure (authors, journal, volume, pages, DOI). All of that is laid out visually on the page, not encoded semantically. GROBID's stated purpose is to extract, parse and re-structure raw documents such as PDF into structured XML/TEI encoded documents, with a focus on technical and scientific publications. The name expands to Generation Of Bibliographic Data.
The audience is narrow and specific. Anyone building a scholarly search index, a citation graph, a reference manager, or a research archive needs the fields that GROBID emits: title, abstract, authors, affiliations, keywords, references, citation contexts, full text structure, and PDF coordinates for the extracted spans. The README lists ResearchGate, Semantic Scholar, HAL Research Archive, scite.ai, Academia.edu, Internet Archive Scholar, INIST-CNRS and CERN (Invenio) as production deployments. That list is the strongest signal about intended use: these are systems that ingest large volumes of papers and need machine-readable metadata rather than pixels.
If your documents are contracts, invoices, or scanned forms, this is the wrong project. The models are trained on scientific and technical publications, and the label set of 68 final labels is built around that domain: journal, volume, issue, DOI, PMID, section titles, reference markers, figure captions, data availability statements. Nothing in the repository suggests general-purpose document understanding.
How the extraction pipeline works: CRF, deep learning, and pdfalto layout features
The architecture is a sequence of models rather than a single end-to-end network. GROBID uses Deep Learning models relying on the DeLFT library, described as a task-agnostic framework for sequence labelling and text classification, connected through JEP. The repository states that GROBID can run deep learning architectures (RNN or transformers, with or without layout feature channels), feature-engineered CRF models, or mixtures of the two.
That choice is the central design decision. CRF is the default according to the README, and it is the lighter path: no Python, no JEP, no GPU. Deep learning models are optional and require Python 3.10-3.11 with JEP, plus an optional NVIDIA GPU with CUDA support for faster inference. The README attributes roughly .87 F1 on an independent PubMed Central set of 1943 PDFs containing 90,125 references, and around .90 on a bioRxiv set of 2000 PDFs, to the Deep Learning citation model. Reference parsing in isolation is reported above .90 F1 at instance level and .95 F1 at field level using the deep learning model. Citation context resolution accuracy is given as between .76 and .91 F1 depending on the evaluation collection.
Those numbers come with their own caveats, which the README states: they are measured on specific collections, and the range for citation contexts is wide. Treat them as the project's own benchmarks, not as a guarantee for your corpus.
Visual information enters through pdfalto, which supplies text and layout information. GROBID also emits PDF coordinates for extracted information, which is what allows a downstream tool to draw bounding boxes and build an interactive PDF. If you need to highlight where a title or a reference was found on the page, that coordinate output is the mechanism, and it is a capability that plain text extraction does not provide.
Consolidation is a separate step. Extracted references can be resolved against the biblio-glutton service or the CrossRef REST API. The README reports DOI/PMID resolution performance higher than 0.95 F1 from PDF extraction in both cases. This is an external network call, so it is a distinct operational concern from the local parsing models.
Getting it running: JDK 21, Docker, and the JEP decision
The requirements section is short and worth reading before anything else. Building from source needs OpenJDK 21. Native builds are supported on 64-bit Linux and macOS (Intel and ARM). Windows is explicitly not supported: the README says support cannot currently be ensured and invites help. Python 3.10-3.11 with JEP is optional and only needed for deep learning models, and an NVIDIA GPU with CUDA support is optional for faster deep learning inference.
The README points to a getting started page, an installation document under doc/Install-Grobid.md, and an upgrade guide under doc/Upgrading.md for version-specific migration notes. Docker images are documented separately, and the repository also advertises a web service API, batch processing, a Java API, and a training and evaluation framework.
The practical decision point is the JEP boundary. If you run the default CRF models, your deployment is a Java service and you avoid the Python interpreter, the JEP bridge, and the GPU question entirely. If you enable deep learning models, you take on a second runtime inside the process, and you need to keep the Python version pinned to the documented 3.10-3.11 range. That is a real constraint: it is not a range you can ignore when your base image ships a newer Python by default.
For batch work, the batch processing path is the one to read, because a web service round trip per PDF is a different operational shape from a bulk run. The repository does not give a single canonical command line in the material available here, so the concrete invocation has to come from the batch and service documentation rather than from the README.
One naming detail that matters when you search for help: the project states its own spelling. It is GROBID, or Grobid, but not GroBid nor GroBiD.
Where GROBID breaks down, and when it is the wrong tool
The most obvious limitation is platform. Windows is not supported, and the README frames this as a support gap rather than a roadmap item. If your processing pipeline runs on Windows hosts, you are looking at containers or a Linux machine, not a native install.
The second is the model dependency. Deep learning models need Python 3.10-3.11 and JEP, and the repository does not present a Python-free way to get the higher reported scores. Teams that want the deep learning accuracy without a second language runtime in the same process have to accept the CRF default and whatever accuracy difference that implies for their documents. The README does not publish a clean CRF-versus-deep-learning comparison for every task, so that trade-off has to be measured locally.
The third is the benchmark range itself. Citation context resolution is quoted between .76 and .91 F1 depending on the evaluation collection. A spread that wide means the collection matters as much as the model. If your corpus differs from PubMed Central or bioRxiv in layout, language, or publisher conventions, the published figures tell you less than you would like.
Finally, there is scope. GROBID targets technical and scientific publications, plus patent and non-patent references in patent publications. It is not a general OCR or document AI system. If your PDFs are scanned images without a text layer, nothing in the described pipeline addresses that; pdfalto supplies text and layout, and the models operate on that representation. And if you only need the raw text of a paper, running a model pipeline to get it is unnecessary work.
GROBID versus plain text extraction and general document parsers
The honest alternative for many teams is not another scholarly parser. It is a text extraction library such as pdfminer or PyMuPDF, or a general document AI service. The difference is what you get back. A text extractor returns a stream of characters and maybe some positional hints. GROBID returns TEI XML with 68 final labels, so a title is a title element, an author has forenames and middle names separated, a reference is a structured record with DOI and PMID where found, and every extracted span can carry PDF coordinates.
That structural output is the whole value proposition, and it is also the cost. You are running a Java service with trained models instead of a library call. For a pipeline that only needs to search the body text of papers, the extractor wins on simplicity and on resource use. For a pipeline that needs to link citations, deduplicate authors, or build an interactive reading interface, the extractor leaves you writing the parser yourself, which is the work GROBID already did.
A second alternative is the hosted route. The repository links a public demo space and Docker Hub images, so you can evaluate output quality before committing to an install. That is a reasonable first step: run a sample of your own PDFs through the demo, inspect the TEI, and decide whether the structure matches what your downstream system expects. The demo is an evaluation aid, not a production architecture, and the README does not describe its capacity or limits.
On consolidation, the choice is between biblio-glutton and the CrossRef REST API. Both are documented as achieving higher than 0.95 F1 for DOI/PMID resolution from PDF extraction. biblio-glutton is a separate service you would run or reach; CrossRef is an external public API. That is a deployment and rate-limit decision as much as an accuracy one.
Maintenance, releases, and what the Apache-2.0 licence means here
GROBID is Apache-2.0 licensed. For most adopters that is a permissive arrangement: you can use it in commercial systems, and the licence does not impose a copyleft obligation on your own code. This is not legal advice, and the licence text plus any third-party model or data licences are what your legal review should actually read. The repository material here does not enumerate the licences of the trained models or of DeLFT, so that is a gap worth closing before shipping.
The release cadence visible in the material is roughly two to three releases a year: 0.8.2 in May 2025, 0.9.0 in April 2026, and 0.9.1 in August 2026. The project describes itself as steady work run as a side project since 2008, made available in open source in 2011, with continuous support from Inria. That framing matters for planning: a side project with institutional backing is not the same as a vendor with an SLA. The README states the tool is considered production ready and lists large deployments, but you should read that alongside the side-project description rather than instead of it.
The upgrade cost is real and the project acknowledges it by shipping a dedicated upgrade guide with version-specific migration notes. If you pin a version and stay on it, the cost is low. If you track releases, budget time for the migration notes between minor versions, because model and dependency changes land in those releases. The Java 21 requirement is itself an upgrade cost for anyone still on an older JDK: moving to GROBID 0.9.x means moving your build and runtime to 21.
Training your own models is possible through the documented training and evaluation framework, with precision, recall and n-fold cross-evaluation, plus semi-automatic generation of training data. That is the escape hatch if the published benchmarks do not hold on your corpus. It is also a commitment: you are now maintaining models, not just a service.
Who should adopt GROBID, and what to check before you do
Adopt it if you are building infrastructure over scientific literature and you need structured output rather than text. The feature list maps directly onto citation graphs, reference managers, and research archives: header parsing, reference parsing, citation context resolution, full text structuring, funder extraction with optional CrossRef Funder Registry matching, and copyright and licence identification. The production deployment list is the evidence that this shape of use is viable at scale.
Do not adopt it if you need Windows-native support, if you only want plain text, or if your documents are outside the scientific and patent domain. Do not adopt it expecting the published F1 scores to transfer without measurement, particularly for citation context resolution where the documented range spans .76 to .91.
Before committing, verify four things. First, run a sample of your own PDFs through the public demo and read the TEI output to confirm the label set matches your downstream schema. Second, decide whether you need deep learning models, because that decision determines whether Python 3.10-3.11 and JEP are part of your deployment. Third, read the upgrade guide for the migration notes that apply between the version you start on and the version you plan to reach. Fourth, check the licence situation for the models and for DeLFT, not just the Apache-2.0 licence on the GROBID repository itself. None of those four steps requires a full install, and each one can change the answer.
Editorial conclusion
GROBID fits teams that need structured TEI XML from scholarly PDFs at scale and can absorb a Java 21 service plus an optional Python 3.10-3.11 JEP environment for deep learning models. It is the wrong tool if you only need plain text, or if your corpus is not technical and scientific literature. Before adopting it, verify the F1 figures against your own document set, confirm whether you will run CRF or deep learning models, and check the upgrade guide for the migration notes between 0.8.x and 0.9.x.
Community notes