biblatex moves LaTeX bibliography formatting out of BibTeX style files

What the package replaces and what it keeps

biblatex provides advanced bibliographic facilities for use with LaTeX, and the project describes itself as a complete reimplementation of the bibliographic facilities provided by LaTeX. That word complete is doing real work in the description, because the traditional setup is a three part arrangement: a .bib data file, a BibTeX program that reads it and a .bst style file that decides both the sorting and the output format. biblatex keeps the first part and the second part in a new form, and discards the third. A custom backend called Biber is used by default, which processes BibTeX format data files and then performs all sorting, label generation and a great deal more. The central architectural point is that biblatex does not use the backend to format the bibliography information as traditional BibTeX does. Instead of being implemented in BibTeX style files, the formatting of the bibliography is entirely controlled by TeX macros. So you end up with data in a .bib file, sorting and label generation in Biber, and the appearance of every entry decided by LaTeX code you can edit and copy into your own project.

The features that distinguish it from BibTeX

The list of what biblatex adds is where the practical case lies. The package supports subdivided bibliographies, and bibliographies may be subdivided into parts or segmented by topics. It supports multiple bibliographies within one document with different sorting, and separate lists of bibliographic information such as abbreviations of various fields. Just like the bibliography styles, all citation commands may be freely defined, so the \cite family is yours to rename or extend. With Biber as the backend, the project lists customisable sorting, multiple bibliographies with different sorting, customisable labels, dynamic data modification and custom data models as available. The custom data model point is the one that separates biblatex from a style file in kind rather than degree. A .bst file can reorder fields and rename the output, but it works against the fixed BibTeX entry schema. A custom data model lets you define new fields and say what they mean, which is what you need when you are working with source types that the original schema never imagined.

Localisation, and how translations are maintained

The package is completely localised and can interface with the Babel and Polyglossia packages, and the README documents how to update or add translations. The language files, with the .lbx extension, live in tex/latex/biblatex/lbx. To add a new translation you copy english.lbx, or another existing translation closer to your language, to languagename.lbx, where languagename is the name Babel uses for that language. Two caveats are stated and both are practical. english.lbx and german.lbx are reference translations, and all other files are not guaranteed to be complete. And if your language inherits from another, you have to take extra care, because new strings are not reported if they are already translated in the inherited language, which means an inherited language can mask gaps in your own file. The verification procedure is documented and is the right way to contribute. Copy doc/latex/biblatex/examples/03-localization-keys.tex to tex/latex/biblatex/lbx, edit it so Babel and hence biblatex uses your language, and compile it. The compile warns about missing strings, and the generated file helps with proofreading. If you are translating for an upcoming release and have cloned the Git repository, you have to build and install the package first before compiling that file.

Installing the stable release versus the development branch

biblatex is bundled with TeXLive and its variants as well as MikTeX, and normally you install and update it through your TeX distribution. That is the path most people should take, and the README frames everything else as a special case. The distribution chain runs from GitHub, where development releases live, to SourceForge, which is where the project is packaged for general consumption and where users can download the current development version, and then to CTAN, where the latest official release is put and where users get the latest stable version. The README advises installing from GitHub only if you want the bleeding edge of development or if there is absolutely no way to obtain the official historical releases from SourceForge or the current release from CTAN. One more constraint is attached to that route: you will need a matching Biber version, with the binaries distributed on SourceForge as well. The version pairing is the thing that breaks most often when a document is built in CI, because a biblatex from one month and a Biber from another can disagree about the .bcf format.

Installing from GitHub on a Unix-like system

The GitHub route requires a UNIX-like system, and on Windows the README points you at Cygwin, with bash and perl needed. You clone the repository first.

git clone https://github.com/plk/biblatex.git

Then, from the clone root, you run the build script with a version and a texmf root.

obuild/build.sh install <version> <texmf root>

The example given assumes the currently released version is 3.3 and that you want to try the 3.4 development version, with your personal texmf root at ~/texmf.

obuild/build.sh install 3.4 ~/texmf

If this is the first time you are installing biblatex into ~/texmf, you have to tell TeX that it can find the files in this new location with texhash or the equivalent command from your TeX distribution. There is a subtlety in the script that is worth understanding before you rely on it. The install script does not fetch and install the official biblatex release corresponding to the version argument supplied. It takes the files that are currently checked out, moves them and changes their version identifications so that they identify as the version given in the argument. If you want a specific version, you must check out the corresponding tag or obtain the corresponding sources before running the script. The README also notes it is easier to get the TDS format package from the SourceForge development folder and unpack it into ~/texmf, though that might not be quite as recent as the git development branch.

Getting help from the example files

The help section points to two places, and the first is the more useful one. The package ships example files in the doc/latex/biblatex/examples directory in the distribution, and there are a lot of practical examples there along with comments in the source .tex files which help explain details not dwelt on in the PDF manual. That is a deliberate complement to the manual rather than a substitute, and the reason to prefer it is that the examples are the working form of the manual. A behaviour that the manual describes in prose is shown as a compilable file with comments explaining the parts that are easy to get wrong. The second source is StackExchange, with a biblatex tag where the question volume reflects how many LaTeX users are working with the package and how many configuration corners there are to get stuck on. For debugging and feature requests, the README says to go to the GitHub issues page, open an issue, and add a minimal working example if possible, which it describes as helping a great deal to facilitate a swift response.

Maintenance, licence and the cost of adopting it

The licence is the LaTeX Project Public License, either version 1.3 or, at your option, any later version, with the latest version of the licence at latex-project.org/lppl.txt and version 1.3 or later part of all distributions of LaTeX version 2003/06/01 or later. The work has the LPPL maintenance status maintained, and the last push to the repository was on 2026-09-24, with the default branch named dev. Copyright runs from 2006 to 2011 to Philipp Lehman and from 2011 onwards to Philip Kime, with Joseph Wright and Audrey Boruvka listed as authors since 2011. The practical upgrade cost is low in one sense and real in another. Low, because your TeX distribution ships biblatex and Biber together and upgrading is a distribution update. Real, because adopting biblatex in an existing project is not a package swap, it is a conversion: the .bst file that controlled your output has no equivalent, and the formatting has to be re-expressed as LaTeX macros, which for a heavily customised bibliography is genuine work. That conversion cost, not the licence or the install, is what usually decides the question.

Editorial conclusion

Adopt biblatex if you write LaTeX and have outgrown what a BibTeX style file can express, particularly if you need subdivided bibliographies, several bibliographies with different sorting in one document, or a data model of your own. Do not adopt it for a one-page document with two references, since Biber and the .bcf workflow add a dependency and a build step for no gain. Verify two things before you convert a project: that your TeX distribution ships a Biber version matching the biblatex version you install, because the README is explicit that a matching Biber is required, and that your editor and CI can run Biber in the build, since a LaTeX toolchain that only knows how to run BibTeX will fail. The practical first step is to install biblatex through your TeX distribution rather than from GitHub, then add a single \printbibliography and check that Biber runs in the build.

Frequently asked questions

Official sources

1. Issues
2. plk/biblatex on GitHub
3. README