Will YouTube Ever Run Out Of Video IDs?

Tom Scott · 10.1M views · 2016 · 5:10

Open on YouTube

Software (other)Internet culture & memesexplainer

Why Hacker News recommends it

HN links it whenever IDs, base64 or random identifier space come up, as a short and pleasant explainer.

What it is

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.

Recommended by 1 HN commenters across 1 different months, 2021 to 2026.

What Hacker News said

Recommends apocalyptic0n3 · 2021-02 · on “YouTubers have to declare ads. Why doesn't anyone else? [video]”

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]

Cites tabletthrowaway · 2021-06 · on ““Older unlisted videos will be made private unless you opt out””

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.

Cites kaliszad · 2021-08 · on “India is leading IPv6 migration with 61.67% adoption”

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...

Cites dajonker · 2023-10 · on “Bye Sequence, Hello UUIDv7”

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 thi

Cites ekipan · 2026-02 · on “Cosmologically Unique IDs”

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