How to check LaTeX citations and BibTeX keys
Build two lists — every key your project cites, and every key your .bib files define — then compare them in both directions. Normalise case before deciding anything is missing, check for keys defined twice, and resolve crossref parents before calling an entry unused. Then compile and read the log, because an undefined citation is a warning and your document will happily build without it.
This is about whether a key resolves to an entry — the bookkeeping between your .texfiles and your bibliography database. It is a different question from whether the entry’s own details are right, which is checked against scholarly records rather than against your project, and the two are easy to run together.
Why this breaks quietly
A missing citation key does not stop a build. You get a warning in the log, a bold key or a question mark somewhere in the text, and a PDF that otherwise looks finished. On a thesis with four hundred citations and a log several thousand lines long, that is easy to miss right up until someone else opens the file.
It also gets worse the longer a project runs. Keys get renamed when a reference manager re-exports, chapters move between files, and .bib files get merged. None of that leaves a mark in the source.
The four ways keys and entries disagree
Cited key with no entry
The key appears in a citation command and nothing in your .bib files defines it. BibTeX reports that it found no database entry; LaTeX then prints the key in bold or as a question mark depending on your style. This is the one that reaches a printed PDF most often, because a single undefined citation does not stop a build.
Case mismatch
You cite Smith2019 and the entry is smith2019. BibTeX keys are conventionally treated case-insensitively by some tools and not others, so this can work on your machine and fail on a co-author's. Worth resolving rather than relying on which backend runs.
Duplicate entry keys
The same key defined twice, usually after merging two .bib files or exporting twice from a reference manager. There is no single entry to resolve to, and which one wins is not something you should be discovering from the output.
Entry nothing cites
A record in the .bib that no citation requests. Harmless for a build, and only sometimes a problem — with a plain numeric style an uncited entry simply never appears. It matters when you meant to cite it, or when a submission asks that the bibliography contain only cited work.
Knowing which commands to look for
Searching for \cite alone misses most of a real project. The two common ecosystems have different vocabularies, and both allow several keys in one command.
natbib
Parenthetical and textual forms are separate commands — \citep and \citet — alongside \citealp, \citealt, \citeauthor, \citeyear and \citenum.
biblatex
A different set again: \parencite, \textcite, \autocite, \smartcite, \footcite — each with a plural form taking several bracketed groups, such as \textcites{a}{b}. Capitalised variants exist for sentence-initial use.
And the ones that cite invisibly
\nocite adds a key to the bibliography with no mark in the text, and \nocite{*} adds every entry in the database. If that appears anywhere in your project, “unused entry” stops meaning anything — everything is used.
BibTeX and biblatex are not interchangeable, and mixing their commands is its own source of confusion: biblatex loads its bibliography with \addbibresource and usually runs Biber, while BibTeX styles use \bibliography without the file extension.
Crossref, and why it changes “unused”
BibTeX’s crossref field lets one entry inherit fields from another: a chapter entry points at the proceedings or collection it appeared in, and picks up the shared title, editor, publisher and year rather than repeating them.
That has a consequence people miss when auditing a bibliography. The parent entry is usually never cited directly — its whole job is to be inherited from. A naive check reports it as unused, and deleting it breaks every child that depended on it. Resolve crossref relationships first, then ask what is genuinely orphaned.
The relationships themselves can also break: a parent key that does not exist, a parent defined twice, a parent referenced with different capitalisation, or two entries pointing at each other in a cycle.
The method
1. Collect every key your project actually requests
Grep the project rather than the root file: keys live in chapter files pulled in by \input and \include. Remember that one command can hold several keys, comma-separated, and that \nocite adds keys with no visible citation.
2. Collect every key your bibliography defines
Pull the @type{key, line from each .bib file the project declares. With BibTeX that is \bibliography{...}; with biblatex it is \addbibresource{...}, and the extension is written out. A file you stopped declaring is still on disk and will quietly stop contributing.
3. Compare in both directions
Requested-but-undefined and defined-but-unrequested are different problems with different fixes. A single pass in one direction finds half of them.
4. Normalise case before you conclude anything
Lowercase both lists and compare again. Anything that matches now but did not before is a case mismatch rather than a missing key, and the fix is different.
5. Look for keys defined more than once
Sort the defined list and look for adjacent duplicates. This is also where near-duplicates from two exports show up.
6. Resolve crossref parents before judging what is unused
An entry used only as the parent of a crossref is not dead weight, even though nothing cites it directly. Check parents before deleting anything the first pass called unused.
7. Build, and read the log rather than the PDF
Undefined citations are warnings, not errors, so the document still produces output. The log is where they are listed — and you may need a second LaTeX pass after running the bibliography tool for the citations to settle.
Three questions people run together
Does the key resolve?
Bookkeeping between your source and your database. Everything above is this question, and it has a definite answer.
Is the entry formatted correctly?
Whether the fields are right and the output matches the style you were asked for. A key can resolve perfectly to an entry with the wrong year or a missing publisher. Checking that means comparing the entry against the published record, which is a different pipeline — the Reference Checker examines entries themselves. The LaTeX project check does not do it: it compares your project against your own bibliography, and never looks a source up externally.
Does the source support the sentence?
Whether the work you cited actually says what you claimed. Nothing about key integrity touches this — it is a separate check entirely, and on a LaTeX project it is one to do by reading.
What StudyRef does here
Upload the project and it resolves every requested key against your .bibentries, across every file the root document includes. Missing, case-mismatched, ambiguous and duplicate keys are reported separately rather than as one “bad citation” bucket, crossref parents are resolved before anything is called unused, and \nocite is understood. It does not compile, so the log still needs reading.
Check a whole project’s citation keys
A .zip of the project, including its bibliography files. Requires an account on a paid plan.
Related
- Labels and cross-references — the same shape of problem, different commands and different failure modes.
- The pre-submission checklist — where this fits among everything else worth checking.