Tom Scott
1 HN recommender · recommended in 7 months, 2021–2026
5:10 · 10M views · Mar 21, 2016
Tom Scott explains YouTube's 11-character video IDs, which are base-64 encoded 64-bit numbers, and whether YouTube could ever run out of them. It covers counting systems and base 64 briefly.
HN links it whenever IDs, base64 or random identifier space come up, as a short and pleasant explainer.
7 comments from Hacker News
Him dancing around and celebrating at the end of his 5 minute explanation of YouTube IDs [1] is such an uplifting thing to watch. 1: this video
Well, have fun guessing 2^64 possibilities. YouTube lists even private videos "secured" using 11 BASE64 characters (66 bits in theory, but they seem to use just 64 bits). You can watch Tom Scott explain it: this video CG-NAT doesn't really prevent geolocation. Better services will still pin-point you to the nearest city. There are perhaps easier ways to get your private info or your money - phishing and ransomware seem to be still very popular. Don't have to hack games that only relatively few people have. It is more profitable to attack a bigger market or more wealthy institutions or companies in foreign countries. Also, if you hack the central game server, you will have a lot more victims... Choose your poison. I guess, there are no games or other software that cannot be audited in high security installations. At home, having a work computer and a game computer (or a VM with GPU pass through or whatever) might be a safer choice in any case independent of IPv4 or IPv6 usage or the quality of your firewall.
I forget the context but the other day I also learned about Snowflake IDs [1] that are apparently used by Twitter, Discord, Instagram, and Mastodon. Timestamp + random seems like it could be a good tradeoff to reduce the ID sizes and still get reasonable characteristics, I'm surprised the article didn't explore there (but then again "timestamps" are a lot more nebulous at universal scale I suppose). Just spitballing here but I wonder if it would be worthwhile to reclaim ten bits of the Snowflake timestamp and use the low 32 bits for a random number. Four billion IDs for each second. There's a Tom Scott video [2] that describes Youtube video IDs as 11-digit base-64 random numbers, but I don't see any official documentation about that. At the end he says how many IDs are available but I don't think he considers collisions via the birthday paradox. [1]: [LINK] [2]: this video
Similar to the old situation in the article, we are using sequential 64 bit primary keys, but we use an additional random 64 bit key for external usage (instead of 128 bit). The external key is base64 encoded for use in URLs which results in an 11 byte string. This hides any information about the size of the data, the creation date of customer accounts (which would be sort of visible with UUIDv7) and prevents anyone from attempting to enumerate data by changing the integer in URLs. I thought about using UUIDs as external keys but the only compelling use case seems to be the ability to generate keys from many decoupled sources that have to be merged later. 64 bit should be enough for most things this video
Obligatory: this video There’s too many IDs to iterate through. Searching for $defatltvideoname for some camera is far more effective for that. Scarily so.