# valid biblatex id

I've been searching in the Biblatex documentation and I couldn't find it.

I was working with some in file bibtex citations using \begin{thebibliography}, and I had spaces in the ids, and there seemed to be no problem. I found Biblatex and just moved the information to a .bib file, playing around helped me notice that  (space) was an illegal character in the biblatex file (cuz the bibliography wouldn't show up until I got rid of it).

I have a lot of citations (which is why I made the switch), is there a way to keep the spaces in the citation ids? What are the rule-sets governing biblatex ids?

• Welcome to TeX.SE. – Mico Oct 4 at 6:23
• By "id", do you mean the entry's key, i.e., the item that comes after the opening curly brace in, say, @article{key, ... }? Please clarify. – Mico Oct 4 at 7:46
• no, you will have to remove the spaces. And your keys shouldn't contain any of the following chars  # % ' " ( ) , = { } (not quite sure about the ", need to check later). – Ulrike Fischer Oct 4 at 9:06
• Is there a way to keep the spaces in the citation ids? Wrong question. It should be: Is there a reason to have spaces in ONE citation key? And the answer is no, no and no. The usual meaning of spaces in any kind of syntax is that something ended and something different start. Even when there are ways to circumvent this meaning (with quotes, escape, braces,..) add spaces within a single thing is search for troubles, no mather the ting is a bibtex key, a filename, a variable code or plain text (is not the same "Disconsolate" that "Disc on so late"). – Fran Oct 4 at 9:52
• tex.stackexchange.com/q/408530/35864, tex.stackexchange.com/q/96454/35864, tex.stackexchange.com/q/243729/35864 should help with your second question. The answer to your first question is that you can't have a space in your entry keys if you want to use BibTeX or Biber (i.e. if you want to use a .bib file). You will have to remove them, sorry. – moewe Oct 4 at 12:13

You remark,

I was working with ... \begin{thebibliography}, and I had spaces in the ids, and there seemed to be no problem.

If one uses

\begin{thebibliography}{99}
...
\bibitem{some key} ...
...
\end{thebibliography}


to create the formatted bibliography, one is not only formatting the bibliographic entries by hand, one is also performing the selection of which entries should show up in the formatted bibliography by hand. As such, having a space in the argument of \bibitem, though by no means encouraged, does not appear to be fatal.

In contrast, if one uses an external program (e.g., bibtex or biber) to create the formatted bibliography, the external program has to rely on the arguments of the various \cite commands to determine which entries need to be extracted from the bib file(s). In order to make this determination successful and unambiguous, the bib entries and their fields must satisfy various lexical rules. One of them is that no whitespace is allowed in the name of the key of a bibliographic entry. This isn't an arbitrary choice. BibTeX and Biber allow whitespace both before and after the key. E.g.,

@misc{ab:2000,
@misc{ ab:2000 ,


are both semantically valid and, indeed, would be considered to have the same key. In contrast, if whitespace were allowed in the interior of the key's name, then

@misc{cd 2010,
@misc{ cd 2010,
@misc{cd 2010 ,
@misc{ cd 2010 ,


could conceivably constitute the beginnings of four separate and distinct entries. To keep the scope for typographic confusion at least somewhat manageable, one would have to disallow whitespace both before and after the key in order to allow whitespace inside the key name. What you lose on the swings, you gain on the roundabouts...

It's worth keeping in mind that BibTeX (the program) has been around for more than 35 years. When BibTeX was first launched, programs to perform lexical analysis were far less powerful than they are today. In my view, Oren Patashnik (the creator of BibTeX) acted wisely by not allowing whitespace in the interior of bibliographic keys, as this simplification freed up some much-needed time to address other, far more pressing software-related issues.