JabRef: a BibTeX-first reference manager for LaTeX workflows

What JabRef solves, and who is actually the target user

Reference managers usually make one of two bets. Either the library is a database the tool owns, or the library is a file you own and the tool edits it. JabRef takes the second position. The README states plainly that the library is saved as a simple text file, which makes it easy to share via Dropbox and friendly to version control. That single design decision explains most of the rest of the product.

The people this fits are LaTeX and BibLaTeX users. The README lists native BibTeX and BibLaTeX support first among the citing features, and describes cite-as-you-write for Emacs, Kile, LyX, Texmaker, TeXstudio, Vim and WinEdt. If your build already reads a .bib file, JabRef is an editor for that file rather than a new source of truth. The same logic applies to groups: a .bib file diffs and merges like any other text file, so a shared repository does not need an export step.

It is a desktop application, not a web service. The repository layout shows jabgui as the JavaFX module, with jablib as the shared library and jabkit, jabls and jabsrv as separate entry points. That split matters for evaluation: the GUI is one consumer of the library, not the whole project.

How the library, the metadata and the sync actually fit together

The mechanism visible in the repository is a layered one. jablib holds the shared logic for reading and writing entries, jabgui is the JavaFX desktop front end, and the remaining modules expose that same logic through other interfaces. jabkit is the CLI, jabsrv and jabsrv-cli are a server, jabls and jabls-cli are a language server, and jablib-examples exists as a sample consumer. So the BibTeX handling is not welded to the window you see.

On the collection side, the README describes fetching complete bibliographic information from an ISBN, DOI, PubMed-ID or arXiv-ID, and extracting metadata from PDFs. It also lists searching across CrossRef, Google Scholar, IEEEXplore, INSPIRE-HEP, Medline PubMed, MathSciNet, Springer, arXiv and zbMATH, plus import support for over 15 reference formats. The browser extension for Firefox, Chrome, Edge and Vivaldi is a separate repository, linked from the README, and pushes references into the desktop app.

Organization is where the .bib model shows its limits and its strengths. Groups are hierarchical and can be driven by keywords, search terms or manual assignment. Duplicate detection and merge exist. Attachments are supported for 20 document kinds, with rules for renaming and moving files. All of that metadata has to live somewhere, and BibTeX's field model is narrower than what JabRef tracks, so the README notes that you can add new metadata fields or reference types. That customization is the escape hatch, and also a portability question: a custom field is not understood by whatever else reads your .bib file.

Installing JabRef and importing your first reference

The README gives two download locations and distinguishes them. Fresh development builds are at builds.jabref.org, and the latest stable release is linked from downloads.jabref.org. The Installation Guide at docs.jabref.org/installation is the canonical reference, and it also covers building from source. There is no package manager command in the README, so treat the installation guide as the place to check for your platform.

The CLI is the one piece the README documents with a runnable command. It is published as a container image, and running it without arguments prints help:

docker run ghcr.io/jabref/jabkit:edge --help

The README also states you can run JabKit using JBang, with details in `.jbang/README.md`. If you are evaluating the project without installing the desktop app, that container is the cheapest way to see what the CLI surface looks like.

For development builds, the repository uses Gradle with a justfile wrapper. The justfile defines a `run` recipe that delegates to the jabgui module, and parallel recipes for the CLI and server modules:

sh ./gg.cmd gradle :jabgui:run
sh ./gg.cmd gradle :jabkit:run --args="{{FLAGS}}"
sh ./gg.cmd gradle :jabsrv-cli:run --args="{{FLAGS}}"

The `gg.cmd` script is downloaded on first use by the `ensure-gg-cmd` recipe, which needs wget or curl on Unix. The Windows recipes use the same Gradle tasks through PowerShell. These are build-from-source paths, not the normal install route for a user.

Once the app is open, the first real workflow is to point it at an existing .bib file or create one, then add a reference by identifier. The README says JabRef can fetch complete bibliographic information based on ISBN, DOI, PubMed-ID and arXiv-ID, so pasting a DOI is the shortest path from nothing to a usable entry. From there the citation key generator produces the key your LaTeX document will reference.

Where JabRef is the wrong tool

The clearest limitation is the release channel. The most recent tagged releases are v6.0-alpha.4 (2025-12-25), v6.0-alpha.5 (2026-02-21) and v6.0-alpha.6 (2026-05-14). All three are alphas. The README's installation section points at a stable release on GitHub, which means the stable line and the tagged line in this repository are not the same thing. Anyone who reads "latest release" as "the alpha" will be running pre-release software. The README does not document a rollback path between major versions, so downgrading a library that has been touched by a newer version is not something the documentation promises to handle.

The second limitation is the deployment shape. This is a JavaFX desktop application. If your team works entirely in a browser, or you need a hosted library that several people edit simultaneously without a shared file or a database, JabRef's primary interface does not match. The README does describe team sync through a SQL database, and the repository contains jabsrv, but the README does not document the server's configuration, authentication or deployment model. Treat that as an open question to resolve before designing a shared setup around it.

Third, custom fields cut both ways. Extending the metadata model is useful inside JabRef, but the README does not describe how those fields survive a round trip through other BibTeX consumers. If your .bib file is read by tools outside your control, test that before relying on custom types.

JabRef compared with Zotero and other reference managers

The comparison people actually search for is JabRef versus Zotero, and the difference in approach is structural rather than a feature checklist. Zotero is built around a local database with its own storage model and a sync service; the library is the application's data. JabRef is built around a .bib file that the application edits. That is why the README can say the library is version-control friendly: a .bib file is text, so git diff and git merge apply to it the way they apply to source code.

The trade-off runs the other way too. A database-backed manager can store richer per-item state without asking whether other tools understand it. JabRef has to keep its extra metadata in a format that BibTeX can carry, which is exactly why the README mentions customizing and adding new metadata fields or reference types. You get portability at the cost of a narrower native schema.

On citation formatting, JabRef uses citation styles, and the README says it can format references with thousands of built-in styles or a style you create. Word and LibreOffice integration exists for inserting and formatting citations, and cite-as-you-write covers a list of plain-text editors. That editor list is the tell: JabRef's integration story is aimed at people writing LaTeX in an editor, not at people writing in a word processor first. If your workflow is a word processor, the integration is there but it is not the design center.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-15, so the codebase is being changed. That is a statement about commit activity, not about release stability: the tagged releases are alphas, and the gap between v6.0-alpha.4 in December and v6.0-alpha.6 in May is roughly two and a half months per alpha. If you depend on a stable channel, your upgrade cadence is governed by the stable downloads page, not by these tags.

The licence is MIT, per the repository. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained, and it comes without warranty. That is the general shape of the licence; it is not legal advice, and if you are redistributing JabRef inside a product or bundling it into a distribution, read LICENSE and the third-party notices in the repository rather than this summary. Note that the repository also carries a PRIVACY.md and an AI_USAGE_POLICY.md at the top level, both of which are worth reading if your institution has policies about either.

The practical upgrade cost is the .bib file itself. Because the library is plain text, upgrading the application does not require a migration step in the way a database-backed tool would. The risk sits in the opposite direction: an older JabRef opening a file that a newer version has written with fields it does not know. The README does not document forward-compatibility guarantees, so keeping the library in version control is the cheap insurance, and the README's own framing of the .bib file as version-control friendly supports that.

Editorial conclusion

Adopt JabRef if your citations live in .bib files and you want a GUI that edits them directly, with a CLI (JabKit) and a sync server (jabsrv) in the same repository. Do not adopt it if you need a stable release channel today: the newest tagged builds are v6.0-alpha.4, v6.0-alpha.5 and v6.0-alpha.6, and the README points stable users at the GitHub downloads page rather than an alpha. Before committing, verify which release channel you are installing from, confirm the Word and LibreOffice integration works with your office version, and check whether the SQL sync backend matches how your group already shares files.

Frequently asked questions

Official sources

1. JabRef/jabref on GitHub
2. License: MIT
3. Project website
4. README
5. Releases