Written and maintained by CASRAI Editorial Board
Last updated
A BibTeX .bib file is a plain-text database of bibliographic records, each one an @entrytype{citationkey, field = {value}, ...} block that a LaTeX document pulls from via cite{citationkey}. The format has been stable since the mid-1980s, which is exactly why small mistakes in it are so common: a missing brace, an un-escaped ampersand, or the wrong field for an entry type produces no on-screen warning in the editor, only a confusing error (or a silently wrong citation) at compile time. This guide is a working reference to the entry-type/field structure, the citation-key convention, and the specific syntax mistakes that most often break a build.
The anatomy of a BibTeX entry
Every record has the same four-part shape:
@article{smith2020,
author = {Smith, Jane},
title = {A Study of Something},
journal = {Journal of Examples},
year = {2020},
volume = {12},
pages = {100--110}
}
- Entry type (
@article) — declares what kind of source this is, which determines which fields are required. - Citation key (
smith2020) — the identifier you pass tocite{}in your document; it is not itself a field. - Fields — comma-separated
name = {value}(orname = "value") pairs, in any order, each one ended by a comma except optionally the last. - Braces — the whole entry is wrapped in
{ }, and each field value is normally wrapped in its own{ }as well.
BibTeX itself doesn’t format anything — it just selects and hands off the fields your chosen bibliography style asks for. That’s why a field BibTeX accepts without complaint (an extra field your style ignores) is harmless, while a field your style needs but your entry lacks produces a broken or blank citation with no compile error at all.
Citation-key convention
The citation key is whatever text follows the opening brace, up to the first comma — smith2020 in the example above. A few rules and conventions that keep keys usable across a growing library:
- Case-sensitive, always.
Smith2020andsmith2020are different keys to BibTeX, even if a carelesscite{}makes that hard to notice until the reference list comes back wrong. - No spaces or commas. The comma ends the key; a space inside one is legal to BibTeX but will trip up some tools that split keys on whitespace, so avoid it in practice.
- Must be unique within the
.bibfile(s) a document draws from — a duplicated key makescite{}ambiguous about which record it means. - Common conventions are author+year (
smith2020), author+year+first-title-word (smith2020study), or a reference-manager-generated pattern (Zotero’s Better BibTeX plugin, for example, defaults to a similar author/year/word template and can enforce it consistently across an entire library so keys don’t drift as new sources are added).
Entry types and their required fields
BibTeX doesn’t hard-enforce required fields at parse time — it will accept an entry missing one. What actually happens is downstream: your bibliography style silently omits or blanks whatever it can’t find. The entry types below cover the large majority of academic sources; fields marked optional are commonly used but not mandatory for that type.
| Entry type | Used for | Required fields | Common optional fields |
|---|---|---|---|
@article |
Journal article | author, title, journal, year | volume, number, pages, month, note |
@book |
Book | author or editor, title, publisher, year | volume/series, address, edition, month, note |
@inproceedings |
Conference paper | author, title, booktitle, year | editor, pages, address, organization, publisher, month, note |
@incollection |
Chapter in an edited book | author, title, booktitle, publisher, year | editor, volume/number, chapter, pages, address, month, note |
@inbook |
Chapter in a single-author book | author or editor, title, chapter and/or pages, publisher, year | volume/number, address, edition, month, note |
@phdthesis |
PhD dissertation | author, title, school, year | type, address, month, note |
@mastersthesis |
Master’s thesis | author, title, school, year | type, address, month, note |
@techreport |
Technical/institutional report | author, title, institution, year | type, number, address, month, note |
@proceedings |
An entire conference volume | title, year | editor, publisher, organization, address, month, note |
@unpublished |
Unpublished manuscript | author, title, note | month, year |
@manual |
Technical documentation | title | author, organization, address, edition, month, year, note |
@misc |
Anything else (datasets, websites, preprints without a better type) | none formally required | author, title, howpublished, year, note, url |
Two patterns worth flagging specifically since the guide’s angle calls them out:
@articlevs.@inproceedingsis the single most common misclassification: a journal article usesjournalfor the venue name, while a conference paper usesbooktitle— putting a conference proceedings title intojournal(or vice versa) doesn’t error, it just produces a citation formatted as the wrong source type, which most style guides and some reference checkers will flag.- Author-or-editor entries (
@book,@inbook) need at least one of the two, not necessarily both — an edited volume with no individual author useseditoralone.
Common syntax errors that break compilation
Most BibTeX failures fall into a handful of repeat patterns:
- Mismatched braces. Every field value’s
{ }pair must balance, and so must the entry’s outer braces. A stray extra}or a missing closing one is the single most common cause of a cryptic"Too many }'s"or"Illegal, another } was found"error, and because BibTeX reports the line where it noticed the imbalance rather than where it actually occurred, the real culprit is often a field or two earlier. - Missing or extra commas. Every field needs a trailing comma except, optionally, the last one before the closing brace. Drop a comma between two fields and BibTeX reads them as one malformed field; add a comma after the entry’s last field and most versions tolerate it, but a comma directly after the citation key with nothing following it does not.
- Unescaped special characters. Field values eventually get passed into your LaTeX document largely as written, so LaTeX’s reserved characters still need escaping inside them:
&as&,%as%,$as$,#as#, and_as_. An un-escaped&in a title likeCost and Benefitwritten asCost & Benefitwill produce a LaTeX misplaced-alignment-character error at the point the reference list is typeset, not when BibTeX itself runs — which is why the error can look unrelated to the bibliography at first glance. - Lost capitalization. Most bibliography styles lowercase title-case fields except the first word and words after a colon. A title containing an acronym or proper noun —
IBM,COVID-19, a country name mid-title — needs the letters you want protected wrapped in their own braces, e.g.{IBM} Research on {COVID-19}. Without the braces, nothing errors; the acronym just silently prints lowercase in the compiled reference list. - Duplicate citation keys. Two entries sharing a key compile without necessarily failing outright, but
cite{}becomes ambiguous about which record it’s pulling from, and different tools resolve the collision differently (first-wins, last-wins, or a warning) — treat any duplicate key BibTeX warns about as a real problem to fix, not noise to ignore. - Non-ASCII characters under classic BibTeX. Accented names and non-Latin text can render incorrectly (or silently drop the accent) under the original
bibtexengine, which predates reliable Unicode handling; either use the LaTeX escape form ('{e}for é) or switch the document to BibLaTeX with the biber backend, which handles UTF-8 natively.
Frequently asked questions
Do I need braces around every field value, or are quotes enough?
Either { } or " " delimits a field value, and BibTeX treats them equivalently for that purpose. Braces are the more common convention because they nest cleanly when you also need inner braces for capitalization protection (title = {A Study of {IBM}}) — a quoted value can’t itself contain an unescaped double quote, which braces don’t have that restriction on.
What’s the difference between BibTeX and BibLaTeX?
They’re different systems built on the same underlying .bib file idea: classic BibTeX pairs with a compact, non-LaTeX .bst style-file language and the bibtex compiler pass, while BibLaTeX pairs with ordinary LaTeX-macro-based styles and the more modern biber backend, which adds Unicode support and a few newer entry types like @online and @dataset. See our LaTeX bibliography styles guide for the full comparison and how to tell which one a journal template is using.
Why does my citation show up as “??” instead of a number?
That’s usually not a .bib syntax problem at all — it means the compile sequence (pdflatex → bibtex → pdflatex → pdflatex) wasn’t run in full, or the citation key in cite{} doesn’t exactly match (case included) a key that exists in your .bib file.
Can I generate a .bib entry automatically instead of typing it by hand?
Yes — most DOIs can be converted directly via content negotiation, and reference managers like Zotero and JabRef export .bib libraries natively. See Getting Clean BibTeX from a DOI for the direct method and the specific field defects (unescaped ampersands, missing capitalization braces, awkward auto-generated keys) that auto-generated records commonly need fixing before use.
Related CASRAI resources
- Getting Clean BibTeX from a DOI — generate a record directly from a DOI and fix the common defects in the output.
- LaTeX Bibliography Styles Explained — how classic BibTeX
.bststyles differ from BibLaTeX/biber, and how compile sequences differ between them. - The RIS File Format Explained — the other widely used plain-text citation format, contrasted with
.bib. - Zotero for Researchers and Zotero Setup and Troubleshooting — reference managers that can generate and maintain a
.biblibrary for you. - How to Use EndNote — the equivalent workflow in EndNote, which uses its own export formats alongside BibTeX/RIS interoperability.
- Citation Styles and Referencing Formats — how the same underlying data renders differently depending on the style applied to it.
- Citation File Format (CITATION.cff) — a different, YAML-based format used for citing software, not to be confused with
.bib.








