1. What I was actually trying to do
I wasn't looking for a product idea. I was finishing a paper, seventy-six references deep into the AI-literacy-in-education literature, and I wanted one thing before it went out: confidence that none of my citations had a dead DOI, or worse, the wrong DOI, silently pointing at someone else's paper. So I did the obvious thing — exported my whole library to BibTeX out of Zotero, the tool I use for every paper I write, the same tool most people in this position reach for. I opened the file expecting to start checking DOIs one by one.
I didn't get that far. The file itself was the problem.
2. A title with a tag's own attributes typed into it
Entry armstrong_when_2014 in my own library is a short, well-cited methods paper on when to correct for multiple statistical comparisons.[1] Its title field, in the file Zotero handed me, read in full:
The real title is “When to use the Bonferroni correction.” Somewhere upstream of Zotero — publisher-deposited metadata does this routinely, to render a name's first letter in small capitals — the title had been recorded as HTML: <span style="font-variant:small-caps;">B</span>onferroni. Zotero can't put a literal < or > into a BibTeX field — both break LaTeX — so its exporter escaped just the brackets, to {\textless} and {\textgreater}, and left everything the tag actually said sitting in the field as plain text. The tag was gone. Its contents — span, style="font-variant:small-caps;", the closing /span — were not. Read as prose, the title of a real, correctly published paper in my own reference list had become:
Zotero's own auto-generated shorttitle for the same entry shows the fault caught mid-collapse, which told me this wasn't a one-off render glitch: whatever truncates a title for Zotero's internal use was operating on the identical corrupted string, with no more idea it was standing in the middle of a tag than the export itself had.
This is exactly the kind of fault that a citation-verification tool has to be built to see through rather than trip over. Compare that string, as written, to the clean title Crossref holds for DOI 10.1111/opo.12131, and there's no overlap worth the name — a false alarm against a citation that is, in fact, exactly right. So the ingest StrictCite runs on any upload resolves the escaped brackets back into a real tag, recognises it as markup rather than as part of the title, and removes it — closing the gap that specific style of tag leaves at a word's first letter, so the comparison reads “Bonferroni,” not “B onferroni.” It does that whether the markup arrives as an actual <span> straight from a registry's own JSON — Crossref and OpenAlex both do this — or, as in my own file, LaTeX-escaped by an export tool that had no way of knowing it was standing in the middle of one.
3. The same mechanism, one field over
A conference proceedings entry further down my own library carries the same fault in miniature. The booktitle field for a 2024 CSEE&T paper[2] read:
This one is doubly encoded rather than half-stripped: the source metadata had already spelled the ampersand out as the HTML entity & — itself a sign something upstream skipped decoding a value it should have — and Zotero's exporter, finding a literal & character sitting inside that entity, escaped it for LaTeX with a backslash on top. Six characters were now doing the work of one. Read literally, my own reference list cited a conference called “CSEE&T,” not “CSEE&T.” StrictCite decodes an HTML entity before any LaTeX-specific handling runs, so a value that already carried one — whichever side introduced it — resolves to the character it was always meant to denote, not to either half of the double encoding.
4. A page count that is a file size
The third fault in my own file wasn't a markup problem at all. A 2025 Melbourne/KPMG report on public trust in AI, deposited on Figshare,[3] carried this:
That number is not a page count. It's the size, in bytes, of the PDF Figshare serves for that record — a figure Figshare's own metadata records alongside the DOI, which Zotero's translator for Figshare items mapped straight into the field it uses for page numbers. Nothing about it looked obviously wrong at a glance; it's a plausible-looking integer sitting exactly where a page number belongs, which is precisely why I'd have missed it reading the file by eye. A locator that doesn't parse as a page number or a range isn't asserted as one by StrictCite's engine: there's nothing on the registry side shaped like “pp. 4,974,511” to compare it against, and a report record with no page range at all isn't a disagreement, so nothing gets raised as if the two sides had actually spoken to different numbers.
5. Why I'm telling you this even if you never use StrictCite
I want to be precise about what this is not: it isn't a reason to distrust Zotero specifically, and it isn't an argument that hand-typed BibTeX fares any better — it doesn't, and it introduces its own class of faults these don't touch. Zotero is still what I use for every paper I write. What changed is that I stopped treating exported by the tool I trust and ready to submit as the same claim. An export inherits whatever a publisher's own page put in the metadata, whatever a registry's deposit pipeline did or didn't decode, and whatever a translator mapped into the wrong field along the way — and it does all of that silently, because nothing in the pipeline between the publisher and my reference list was ever positioned to notice.
So the advice here isn't really a pitch. Building StrictCite is how I ended up able to check for this automatically, but the underlying point stands regardless of what tool you use: don't take an export from Zotero, or Mendeley, or EndNote, or anything else, as clean prose-ready text just because a piece of software you trust produced it. One field like this, carried over unnoticed from a first draft, survives every revision after it for the same reason I almost missed it — nothing about it looks wrong until something actually reads it. It can ride along through months of edits and land, untouched, in the reference list of a camera-ready paper with your name on it.
If you want to see what your own library's export actually contains, field by field: strictcite.com. The free tier requires no card.