Your Bibliography Is a Plain-Text File You Own

Your bibliography is a plain-text file you own — a BibTeX .bib or a CSL-JSON .json that sits beside your notes, not a row locked inside a reference manager's database. Keep the citation itself, in an open format, and it will outlive whichever app you use to edit it.

The formats are older and more durable than most of the apps built on them. BibTeX was written by Oren Patashnik, who implemented Leslie Lamport's basic design; its first public release, version 0.98, shipped in March 1985.¹ Patashnik describes the program plainly: "BibTeX is the bibliography program designed originally to accompany Leslie Lamport's LaTeX; it now works with other incarnations of TeX, too."¹

CSL-JSON is the younger, manager-neutral sibling — the input format for the Citation Style Language, an open specification maintained by a community project that keeps "over 10,000 free CSL citation styles."² Neither format belongs to a company. Both are human-readable text you can open in any editor, grep from a terminal, and track in version control. The manager is a convenience; the file underneath it is the asset.

The one habit: keep the citation, not the app

The single habit is this: treat the citation as a file, not as a record inside an app. Export a .bib or .json and store it next to the notes that cite it. The manager can crash, lapse, or lock you out — the plain-text file stays readable, and every tool can read it back.

The reference managers agree, if you read their own documentation. Zotero's import page lists the formats it accepts as "Zotero RDF, CSL JSON, BibTeX, BibLaTeX, RIS" and treats them as bidirectional interchange — the same list it exports.³ The app itself considers BibTeX and CSL-JSON the portable unit. The database is a working surface; the file is what leaves the building intact.

The database is the silo. The citation is not.

Write one BibTeX entry (the five-minute version)

Start with one reference in a file named refs.bib. A BibTeX entry is a type, a citekey, and a short list of fields. For a journal article, Patashnik's own documentation lists the required fields as author, title, journal, and year, with volume, number, and pages optional.⁴

Here is a real, well-known reference — Claude Shannon's 1948 paper — written as a @article entry:

@article{shannon1948,
  author  = {Shannon, C. E.},
  title   = {A Mathematical Theory of Communication},
  journal = {The Bell System Technical Journal},
  year    = {1948},
  volume  = {27},
  number  = {3},
  pages   = {379--423}
}

Five minutes, seven small decisions:

1. Create the file. refs.bib, in the same folder as the note that cites it.
2. Choose the entry type. @article for a journal paper, @book for a book, @inproceedings for a conference paper.
3. Pick a citekey. shannon1948 — author plus year is a durable convention.
4. Fill the required fields. author, title, journal, year.⁴
5. Add the optional fields you have. volume, number, pages.
6. Save. It is plain text; there is nothing to compile yet.
7. Guard the key. Better BibTeX's author, Emiliano Heyns, puts it well: "As the citation key is the piece of data that connects your bibliography, this is a piece of data you want to have control over."⁵

The citekey is the thread that ties a note to its source. Choose it deliberately, and it stays stable across every tool that reads the file.

Get its CSL-JSON twin (the manager-neutral format)

CSL-JSON is the same citation expressed as JSON, the format most tools speak natively. Every field maps: author becomes a family/given pair, journal becomes container-title, year becomes an issued date-parts array. The CSL project publishes the input schema, so each key is documented, not guessed.⁶

Here is the Shannon entry again, as CSL-JSON in a file named refs.json:

[
  {
    "id": "shannon1948",
    "type": "article-journal",
    "author": [
      { "family": "Shannon", "given": "C. E." }
    ],
    "title": "A Mathematical Theory of Communication",
    "container-title": "The Bell System Technical Journal",
    "volume": "27",
    "issue": "3",
    "page": "379-423",
    "issued": { "date-parts": [[1948]] }
  }
]

Every key above is present in the published csl-data.json input schema, and article-journal is one of its documented type values.⁶ The mapping is mechanical:

You rarely type CSL-JSON by hand — a manager or converter emits it. But knowing the shape means you can read it, diff it, and fix it, which is the point of owning a text file.

Beyond one article: books and multiple authors

Most bibliographies are not one journal article. A book uses @book, whose required fields Patashnik's documentation gives as author or editor, title, publisher, and year.⁴ Multiple authors are just repeated names — Lastname, First and Lastname, First in BibTeX, or a list of family/given objects in CSL-JSON. The same file holds every type.

Here is a two-author book — Kernighan and Ritchie's The C Programming Language — as a BibTeX @book:

@book{kr1988,
  author    = {Kernighan, Brian W. and Ritchie, Dennis M.},
  title     = {The C Programming Language},
  publisher = {Prentice Hall},
  year      = {1988},
  edition   = {2nd}
}

The and between authors is BibTeX's separator, not part of a name. In CSL-JSON, the same two authors become an ordered list, each with its own family and given keys — both of which are documented in the CSL input schema:⁶

"author": [
  { "family": "Kernighan", "given": "Brian W." },
  { "family": "Ritchie",   "given": "Dennis M." }
]

An edited volume swaps author for editor; a chapter uses @incollection with its own booktitle. You do not need to memorize the whole vocabulary — you need to know it is a documented vocabulary, written in text, that you can look up and correct by hand. That is the difference between a format and a black box.

Drop it into a Markdown note with Pandoc

To turn either file into formatted citations inside a Markdown note, use Pandoc with the --citeproc option. Point it at your .bib or .json, write [@shannon1948] where a citation belongs, and Pandoc does the rest — John MacFarlane's manual describes the flag as "Process the citations in the file, replacing them with rendered citations and adding a bibliography."⁷

A note that reads Shannon founded information theory [@shannon1948]. becomes fully cited, with a reference list appended, from one command:

pandoc notes.md --citeproc --bibliography=refs.bib -o notes.pdf

A sentence you write as Shannon founded information theory [@shannon1948]. renders as Shannon founded information theory (Shannon, 1948), with a full reference appended at the end of the document. The key never leaves your note; Pandoc reads the file, resolves the key, and formats the rest.

Pandoc does not care which format you keep. Its manual states that a bibliography "may have any of these formats" and lists them by extension: BibLaTeX .bib, BibTeX .bibtex, CSL JSON .json, RIS .ris.⁷ That is the freedom of an open format — the same [@shannon1948] in your Markdown renders to PDF, HTML, or a Word document, from a file you never had to unlock.

Keep it synced out of your manager

If you live in Zotero, you do not have to choose between the app and the file — you can have both. Better BibTeX, an open Zotero extension, offers "auto export of collections or entire libraries when they change," so a fresh .bib sits beside your notes at all times.⁸

Better BibTeX exists precisely for people who work in text. Its own description says it "makes it easier to manage bibliographic data, especially for people authoring documents using text-based toolchains (e.g. based on LaTeX / Markdown)."⁸

Zotero, Pandoc, and Better BibTeX are the export path, not the enemy — each one hands you the same open file. The tool that curates references and the file that keeps them are two different things; the second is the one that lasts.

What plain text actually buys you: grep, diff, git

Because the file is text, it plugs into tools a database cannot. You can grep for every paper by an author, diff two versions of the library to see what changed, and commit refs.bib to Git so every edit has a history. A binary manager database gives you none of that.

The payoff is concrete on an ordinary day. Searching a thousand-entry library for one author is a single line:

grep -i "Shannon" refs.bib
git log --oneline refs.bib   # every change to your bibliography, dated

None of this needs the manager running, or online, or even installed. A citation you can search, diff, and version is a citation you can trust to still be there — and to still make sense — in ten years. That is what a proprietary database cannot promise, because you cannot read it without the program that wrote it.

Where the two formats disagree (the honest caveat)

Converting between BibTeX and CSL-JSON is lossy at the edges. The two models do not map one to one: name particles like van and de, month and date encoding, and custom fields all round-trip imperfectly. That is not a reason to distrust the formats — it is the reason to keep the raw file, not just the app's copy.

Because a conversion can quietly drop or reshape a field, the source file you authored is the source of truth. A few common mistakes follow from ignoring that:

• Trusting the manager's database as your only copy. If the app is your sole store, you have no plain-text fallback when it fails.
• Treating a converted .json as identical to the source .bib. It usually is not, at the margins — keep both if the details matter.
• Letting the citekey churn. A key that changes breaks every note that referenced it; control it, as Heyns advises.⁵
• Storing the file somewhere far from the notes. A bibliography three folders away from the note that cites it drifts out of sync. Keep them together, and name them predictably — the same discipline as naming your note files and keeping metadata in YAML frontmatter.

How this fits a plain-text note you keep

A .bib or .json is plain text, so it lives wherever your Markdown notes live — on your own device, offline, grep-able and diff-able beside the note that cites it. In a local-first, plain-text editor like MNMNOTE, the reference file is simply another note you own, not an export you have to remember to make.

This is the same argument Markdown makes for prose, applied to references: an open, documented format outlasts the tool that reads it. For the inline citation syntax inside a note — the [^1] footnotes themselves — see footnotes and citations in plain Markdown. For keeping a source's provenance intact, see saving the answer with its sources. The through-line across all of them is one idea: the file is yours, and the app is a guest.

Frequently Asked Questions

Short answers to the questions researchers actually ask when they try to pull a bibliography out of an app and into a file they control. Each answer points back to the primary documentation, so you can verify it against the tool you already use rather than take it on trust.

What format should I use to store my bibliography for the long term? BibTeX (.bib) or CSL-JSON (.json). Both are open, human-readable text. CSL is "an XML-based format to describe the formatting of citations, notes and bibliographies," with an open input schema for the data itself.⁹⁶ BibTeX has been a documented format since 1985.¹ Either survives the app you used to make it.

How do I export a .bib file as plain text from Zotero? Zotero exports BibTeX directly through File → Export Library (or right-click a collection). For a copy that updates itself, install Better BibTeX, which offers "auto export of collections or entire libraries when they change."⁸ The output is ordinary text you can store beside your notes.

Can I export CSL-JSON from Zotero? Yes. CSL JSON is a first-class Zotero import and export format, listed alongside Zotero RDF, BibTeX, BibLaTeX, and RIS in Zotero's own documentation.³ Export it the same way you export BibTeX, and you have the manager-neutral version of the same library.

How do I import plain-text references in BibTeX format? Use File → Import and select your .bib file. Zotero reads BibTeX and BibLaTeX among its standardized formats,³ so a plain-text bibliography moves into the app as cleanly as it moved out — the round trip is what makes the file portable.

Is BibTeX only for LaTeX? No. BibTeX began "designed originally to accompany" LaTeX, but Patashnik notes it "now works with other incarnations of TeX, too."¹ More to the point, CSL-JSON is the manager-neutral sibling, and Pandoc's --citeproc renders either format into PDF, HTML, or Word.⁷ You are not tied to LaTeX to keep a plain-text bibliography.

Won't converting between formats lose data? At the edges, yes. Name particles, month and date encoding, and custom fields do not map one to one between BibTeX and CSL-JSON. Keep the raw file you authored as the source of truth, and treat any conversion as a derived copy — which is exactly why owning the plain-text file matters.

Is the 1985 date real? Yes, and it comes from the format's creator, not folklore. Patashnik writes that "the first public release of BibTeX, in March 1985, was version 0.98," with his own work on the program starting in February 1983.¹ The format is older than most of the software that reads it.

Where should I keep the .bib file? Beside the notes that cite it, in the same folder, under a predictable name. A bibliography that lives three folders away from your writing drifts out of sync and gets forgotten. Co-locating the reference file with the note — and committing both to version control — keeps the citation and its use in one place you can back up as a unit.

A reference manager is a place to work. The citation is the thing worth keeping — and a citation you can read in a text editor is a citation no company can take back.

MNMNOTE keeps your Markdown notes and the plain-text files beside them on your own device, in the open — mnmnote.com.