Tooling (CSL / arXiv / managers)

What actually eats your time in a bibliography is not typing .bib entries. It is keeping one single .bib consistent across a thesis, three submissions and two co-authors. That is why most LaTeX bibliography tools are designed less to speed up entry than to find what broke after entry. This page follows the whole path — pulling records from a DOI or arXiv, scrubbing the dirty ones, killing duplicates, and pinning citation keys before you hand the file to a co-author — using both reference managers such as Zotero and JabRef and the command-line helpers bibcop, checkcites and biber --tool that TeX Live already installed for you.

Getting BibTeX out of a DOI or an arXiv ID

If a paper carries a DOI, its .bib entry is one command away. The mechanism is content negotiation: tell doi.org in an HTTP header that you want BibTeX back, and the agency that registered the DOI — usually Crossref for scholarly articles — formats its metadata as a BibTeX entry and hands it over. You never open the publisher’s page: the DOI itself is the API.

# fetch BibTeX for a DOI; -L follows the redirect to the registration agency
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

Drop the -L and you get nothing. doi.org is only a desk that works out which agency holds the metadata and redirects you there, so without following redirects the request dead-ends. If the command line feels fussy, paste the DOI into doi2bib.org, which wraps the same content negotiation in a web page (it also takes arXiv and PubMed IDs). An arXiv preprint offers “Export BibTeX citation” on its abstract page, and Google Scholar hides the same thing behind “Cite → BibTeX” on each result. Whichever route you take, you type almost nothing.

Why imported BibTeX is almost never usable as-is

Because an exporter simply dumps the strings sitting in its own database; it knows nothing about LaTeX’s needs. Pull the same paper from the publisher’s site, from Crossref and from Google Scholar and you will get three different BibTeX entries. The same four things break every time, and every one of them only surfaces once the bibliography is typeset.

• Capitals are not protected. Unless the title wraps them in braces — {DNA}, {Fourier} — plain-family styles will lower-case them into “dna” and “fourier”. The database page covers the mechanics.
• Journal names are abbreviated, or not. The same journal arrives once as Comput. J. and once as The Computer Journal, and the reference list ends up inconsistent with itself. Submission guidelines almost always demand one or the other.
• The entry type is wrong. Conference papers are frequently exported as @article or @misc, and an @inproceedings with no booktitle typesets into nonsense.
• The arXiv version is mistaken for the published one. A preprint’s BibTeX usually has neither journal nor doi, so you keep citing the old record long after the paper appeared in a refereed venue.

Linting and normalizing a .bib: bibcop and biber --tool

Rather than hunt for those four by eye, let a linter do it. TeX Live already ships bibcop, a linter written for .bib files: no extra install, just bibcop refs.bib. What comes back is not a column of line numbers but complaints in plain sentences — Do not shorten the words in the journal, such as Comput., All major words in the title must be capitalized, A mandatory doi tag for @article is missing. Being told off in readable English leaves no doubt about what to fix.

# lint a database in place
bibcop refs.bib

# reformat and sort every entry; also reports duplicate keys
biber --tool --output-align --output-fieldcase=lower \
  --output-file=clean.bib refs.bib

The reformatting itself is biber --tool’s job. Besides the ordinary mode that processes a document, biber has a tool mode that acts as a standalone filter: .bib in, .bib out. It re-lays the fields in aligned columns, sorts the entries, and if two entries share a key it warns Duplicate entry key: ... skipping and drops one. There is a trap here, though. Tool-mode output is normalized to biblatex field names by default, so year turns into date and journal into journaltitle. For a biblatex document that is exactly what you want; run a .bib destined for plain BibTeX through it and the years and journal names vanish from your reference list.

Finding duplicate entries and orphaned citation keys

When the same key appears twice, BibTeX says Repeated entry---line 8 of file refs.bib and throws away the later one; biber warns Duplicate entry key. The nastier case is the duplicate with different keys but identical content, which nothing warns you about. Merge two co-authors’ Zotero exports and the same paper sits there twice as smith2020 and Smith2020a — an accident you normally discover when the same line appears twice in the printed bibliography.

For content-based matching, the most reliable clue is the DOI. Author names and titles drift, but two entries with the same DOI are the same paper, full stop. bibtex-tidy implements exactly that: pick the criterion with --duplicates doi (or key, abstract, citation) and add --merge to fold one into the other. The opposite problem — citing a key the .bib does not contain, so the text prints [?] — is what checkcites is for. --undefined lists keys you cite but never defined; --unused lists entries you defined that nobody cites.

# BibTeX projects read the .aux; biblatex projects read the .bcf
checkcites paper.aux
checkcites --backend biber paper.bcf

# keys cited but missing from the database
checkcites --undefined paper.aux

Which reference manager to choose: Zotero, JabRef, BibDesk

Up to a few dozen entries you can edit the .bib by hand; at a few hundred you need a manager. The fork in the road is whether the .bib is the original or an export. JabRef and BibDesk open and save the .bib itself, so they coexist happily with editing the file in a text editor. Zotero treats its own library as the original, and the .bib becomes a derived artifact generated from it.

• Zotero — the free, open-source default. A browser connector captures a paper in one click, stores the PDF, and supports shared group libraries. If you write LaTeX, treat the Better BibTeX add-on as effectively mandatory.
• Better BibTeX (Zotero add-on) — generates citation keys from a pattern and offers auto-export, which pushes every library change straight into your .bib. That is the whole point of it: the .bib becomes an always-current build artifact.
• JabRef — an open-source manager that works on .bib natively. It has no separate internal format, fetches entries from a DOI, arXiv ID or ISBN, and offers a bulk cleanup pass over selected entries. It runs on Windows, macOS and Linux.
• BibDesk (macOS) — a BibTeX front-end for the Mac that comes bundled with MacTeX (/Applications/TeX/BibDesk.app). It edits the .bib directly and handles automatic PDF filing and external database searches.
• Mendeley — the old Mendeley Desktop was withdrawn on 1 September 2022, and its automatic .bib syncing went with it. The successor, Mendeley Reference Manager, can still export BibTeX, but only as a manual step.
• Paperpile — a paid service, strong on Google Docs integration, that also exports BibTeX.

The Zotero side of this shifted in 2026. Zotero 8 made the citation key a native Zotero field, superseding the key slot Better BibTeX used to own. Keys are now always pinned and sync between machines, so the old ritual of right-clicking each item to “Pin BibTeX Key” is gone. But Zotero itself does not generate keys — building them from a pattern, and keeping a .bib up to date via auto-export, is still Better BibTeX’s job. Note also that Better BibTeX has ended support for Zotero 7, so this setup means keeping Zotero current too.

Pinning citation keys and sharing a .bib with co-authors

A citation key is the API between the manuscript and the bibliographic database, which is why keys are the one thing that must never move. If your export is configured to re-derive keys each time, every \cite{...} in the body stops resolving at once and the PDF fills with [?]. The convention itself hardly matters, but surname + year + short title — something like knuth1984literate — collides rarely and has the side benefit that the key alone tells you which paper it is.

For sharing, the least accident-prone arrangement is to put the .bib in the same Git repository as the manuscript. It is plain text, so diffs are readable and the history records who added which entry. Left alone it will conflict constantly, though, and the fix is to fix the output order. Have everyone run biber --tool before committing, or point Better BibTeX’s auto-export at one agreed path — either way, once line order is stable, merge conflicts drop off a cliff. What you must not do is mail each other your local .bib files. Two weeks later there are four different .bib files.

# ship only the entries this paper actually cites
pdflatex paper.tex
bibexport -o submission.bib paper.aux

Just before submission the flow reverses: you need to carve a .bib out. Most journals want the full manuscript source, and you cannot ship your 800-entry personal database with it. bibexport reads the .aux and writes only the entries actually \cited into a fresh .bib, which is exactly the shape of this problem (bibtool can analyse the .aux and do the same). For the same reason, keeping one large master .bib and carving a slice per manuscript tends to be the easier arrangement day to day.

Handing the same .bib to people who do not use LaTeX: CSL and pandoc

Even if a co-author is writing in Word, you do not have to abandon the .bib. CSL (Citation Style Language) is an XML format for describing how citations and reference lists look, and its defining property is that it is independent of the typesetting engine. A BibTeX .bst works only with BibTeX and a biblatex style only inside LaTeX, but a .csl is tied to nothing. The formatting is carried out by a citeproc processor, and Zotero, Word plugins and various converters each read the same .csl through their own citeproc implementation. Zotero’s style repository holds thousands of journal styles, free to use.

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

The tool that leans hardest on CSL is pandoc. Convert a Markdown manuscript with --citeproc and citation keys in the body such as [@knuth1984] become formatted citations, with a reference list appended at the end. --bibliography takes your .bib as it stands (and may be repeated to merge several), and omitting --csl falls back to Chicago author-date. In short: the same .bib feeds output straight from Markdown to PDF, Word or HTML, with no LaTeX in the path.

In the end every tool on this page rests on the same premise: the asset is the .bib, not the output route. Once you have one database — pulled in from DOIs, told off by bibcop, tidied by biber --tool, keys pinned, sitting in Git — then producing a PDF through biblatex or handing a co-author a Word file through pandoc is merely a choice of exit. Keeping the database singular pays off far more than adding tools.