Purplelink
← All posts

June 17, 2026

Where BibTeX errors actually come from

By ·

Most BibTeX errors don't come from researchers making mistakes. They come from the bibliography managers and export tools researchers trust to get it right.

When I built the BibTeX validator, I expected it to catch the kind of mistakes researchers make directly: a misspelled author name, a missing journal field, a stray character in a citekey. The mental model was proofreading. Someone writes their bibliography, the validator flags their typos, they fix it.

That's not what happens.

Most of the errors the validator flags come from software exports, not from researchers. Mendeley, Zotero, Google Scholar, Scopus, even publisher download pages: each one produces BibTeX that's subtly wrong in its own way. Google Scholar omits the month field and sometimes drops page numbers entirely. Mendeley serializes the author field correctly but writes DOIs into the url field, which breaks certain bibliography styles. Zotero handles most entry types well but produces nonstandard output for conference papers. Some export tools write month as a number; others use the three-letter abbreviation LaTeX expects; others use the full word, which requires extra package support to parse.

None of these are researcher errors. The researcher opened their bibliography manager, exported to BibTeX, and dropped it into their project. The software they trusted to get this right didn't.

That reframing changed how I built it. A compatibility layer between incompatible software is a different job than a proofreader, and it needs different checks.

It also meant rethinking what "valid" means. A BibTeX file that compiles without errors in one journal's template will sometimes fail in another. Some styles require number fields that others ignore. Some demand a publisher entry for book chapters; others don't care. The BibTeX spec is loose enough that valid-by-spec isn't the same as valid-in-practice, and in-practice depends on which packages you're using.

The validator now checks against what commonly-used packages actually expect, not just what the original 1985 spec requires. It also surfaces a category of warnings that aren't errors: fields that will compile fine today but may cause problems if the researcher switches to a different bibliography style later. Whether to act on a warning is the researcher's call.

The thing I didn't see coming: the warnings are what researchers find most useful. The errors they already knew about. The subtle compatibility issues they didn't.

I started this with a proofreading metaphor. The more accurate one is translation. The validator is reading what four different pieces of software produced and telling you what will and won't survive the trip to the journal template.

← Back to blog