If you haven’t seen Will YouTube Ever Run Out Of Video IDs?, it’s worth a watch, not only because Tom Scott recorded the 5-minute video in a single take, but also because in the middle of it he managed to recite seventy-three quintillion, seven hundred eighty-six quadrillion, nine hundred seventy-six trillion, two hundred ninety-four billion, eight hundred thirty-eight million, two hundred six thousand, four hundred sixty-four from memory.

There’s only one problem: he recited the wrong number.

Actually, there are a few problems^*, but first, let me provide some background.

The day after I saw the video, I needed to write some code at work to encode a random number in a non-decimal base for similar purposes. The function I was using to generate random numbers (openssl_random_pseudo_bytes) required a single parameter: the length of the random number to generate in bytes. Initially I was planning on encoding the random number in hexadecimal (base 16) because every hexadecimal digit (0-9, A-F) corresponds to a sequence of 4 binary digits (or bits), as shown in the following table.

Thus every byte (8 bits) returned by the random number generator can be encoded perfectly using 2 hexadecimal digits. For example, the byte 11010011 in binary equals D3 in hexadecimal (or 211 in decimal). The largest byte, 11111111, equals the largest 2-digit hexadecimal number: FF (or 255 in decimal). This is what I mean by a perfect byte encoding—there are no greater values possible with 2 hexadecimal digits.

But what if I encoded the random number in base 64? Turns out base 64 doesn’t encode bytes as neatly as hexadecimal. Every base 64 digit corresponds to a sequence of 6 bits, so the only time when base 64 perfectly encodes whole byte values is when the number of bits is divisible by 6. This is the case for 3 bytes (24 bits), 6 bytes (48 bits), 9 bytes (72 bits), and so on. You can certainly encode any byte value that is not a multiple of 3 in base 64, but you would leave some possible base 64 values unused. Here’s a table that shows the relationship between bytes, bits, and base 16 and 64 digits.

Which brings me back to YouTube. Why did they choose an 11-digit base 64 number for their video IDs, and not 8 or 12 or 16 digits? The answer has to do with that function for generating random numbers I referenced earlier. How long of a random number in bytes would one need to generate so that number encoded in base 64 would require 11 digits? Based on the table above, 8 bytes (64 bits) require 10⅔ digits in base 64, and since you can’t have ⅔ of a digit, 11 digits would be necessary to encode all possible 8-byte values. This discovery was unsurprising because 8 bytes is a common size for storing and calculating very large numbers. For instance, in a relational database, where one might store a video ID as an integer, the BIGINT data type requires 8 bytes.

This was my ah-ha moment. Though it’s possible that YouTube stores video IDs as 11-character strings, it’s far more probable that they generate and store video IDs as 8-byte integers, which they then trivially encode as 11-digit base 64 numbers used in their URLs. And if that’s the case, the largest unsigned 8 byte value they could generate is “only” 18 quintillion and change (18,446,744,073,709,551,615 to be precise) which is ¼ of the 73 quintillion value Tom Scott masterfully recites in his video (73,786,976,294,838,206,464 to be precise) which he arrived at by calculating every possible integer that an 11-digit base 64 number could encode (2⁶⁶).

I’m not claiming that YouTube stores video IDs in a relational database (though they may have at some point pre-Google), but I think it’s far more likely that they generate random 8-byte (64-bit) integers for their video IDs, as opposed to 66-bit integers. Keep in mind that 18 quintillion is the mathematical maximum. As Tom Scott rightly suggests, they probably reject any numbers whose base 64 encoding is a word in the dictionary (which must be pretty amusing code, having to filter for words across a variety of languages as well as any leetspeak variants).

If you need further evidence, I took the video IDs from the top 100 YouTube videos of all time, and converted them to integers. The greatest base 64 video ID on the list, _Z5-P9v3F8w, was, no surprise, 18,275,183,150,654,494,668 in decimal. As hypothesized, no video IDs breached the 8-byte (18 quintillion) threshold.

I should add that if YouTube ever ran out of video IDs (the horror!), they probably wouldn’t add a 12th character to the base 64 number as Tom Scott suggests, they’d start generating random 10-byte numbers, which would require 14 digits in base 64—giving them a cool septillion video IDs to use—for the rest of eternity.

There’s one last subtle error in the video that I wanted to point out. The base 64 digits in the video are displayed starting with 0-9. However, according to the base 64 standard (RFC 4648) the digits should be ordered from A-Z, then a-z, then 0-9, followed by + and / (or – and _ for use in URLs and filenames). Zero is 0 in base 2, 0 in base 10, 0 in base 16, and A in base 64.