For example, the video IDs that YouTube uses are not a simple number, but instead a case-sensitive, alphanumeric string (like dQw4w9WgXcQ). Why do some websites, such as YouTube and Dailymotion use an alphanumeric string for these IDs instead of using a plain number?

An obvious answer might be because the resulting IDs are then shorter (encoding them in, for instance, Base-64 instead of Base-10), but what I find interesting is that other websites such as Vimeo do not use this technique.

Is there another good reason?

  • 3
    Ever consider what kind of distributed database architecture some big video sites may have that could require the use of GUIDs to prevent collisions?
    – JB King
    Nov 3, 2015 at 18:33
  • 1
    So you are saying that instead of incrementing, different key-spaces are chosen to allow multiple database-nodes to issue video-IDs independently? That certainly makes sense.
    – Qqwy
    Nov 3, 2015 at 18:49
  • 1
    You can interpret any string as a number and any number as a string, so I don't see a big difference here. The shorter encoding seems like a plausible reason to not restrict one to the ten characters for decimal encoding.
    – 5gon12eder
    Nov 3, 2015 at 19:09
  • 8
    Can this question be answered definitively by anyone other than a YouTube engineer? If not, it may not be a good fit for this site. Nov 3, 2015 at 19:14
  • This might also be UserExperience.SE question, because there may be an answer there. One thing I can think of on the back end is that sanitizing the alphanum strings may be easier because, once you check for invalid characters, there is no such thing as an invalid string, while it may be harder to tell that 65535 is a valid number but 65536 is too big, without using even more parsing power than the alphanum took.
    – Cort Ammon
    Nov 3, 2015 at 19:36

3 Answers 3


First, see the CAP Theorem. It's similar to the old aphorism of "Fast, Good, Cheap: Pick 2."

In theoretical computer science, the CAP theorem, also known as Brewer's theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

  • Consistency (all nodes see the same data at the same time)
  • Availability (a guarantee that every request receives a response about whether it succeeded or failed)
  • Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)


Maintaining a serialized number requires consistency... one place that is the keeper of numbers. In large systems this can become a bottleneck, a single point of failure, or both. In distributed systems, it is common to start relaxing this constraint (Consistency) in favor of the other two.

There are strategies to maintain serialized numeric identities in distributed systems, like the HI-LO algorithm or its derivatives, but it is still very possible to skip large swaths of numbers in case of node failures.


Another common method is to use a UUID, a randomly generated identifer (which is twice the size of Int64), which has a pretty high (but not 100%) chance of being unique from any other generated UUID. It's basically just a very large random number. This is nice for client operations, because the client can generate it with a pretty good chance of uniqueness, and subsequently use it to identify or track things. But collisions (same ID being generated) are possible (especially if the client has a terrible RNG) and still must be dealt with.

My suspicion is that the youtube identifers are some shorter variation of a uuid which is then converted to a variation of base64 without punctuation. Because punctuation kills the ability to be used in links. Hence, it's a very large number (either random or serialized) that has been converted to text so that it is shorter.


One identifier format that is fairly popular is "entity-#" or "system-entity-#" if you have a number of inter-operating systems. The # is generated either consistently by the owning system (still distributed in the sense that there are multiple systems, microservices, whatever) or with a HI-LO variation. And for display purposes, it's fairly trivial to strip off the prefix and just use the number portion.


The above is obviously not a complete list, and in the end they are all just binary numbers on disk. The reasons to use one or the other are the architectural trade-offs that are most favorable to your system. UUIDs have the most convenient architectural properties for distributed systems, but are bad with the human factor (user can remember and type 102875, but not B9FE6378-E76C-40D5-883B-72FE376952A4, a UUID I just made).

If there is any ambiguity in what is being identified, neither UUIDs or numbers are particularly useful but strings are great there. At least serialized numbers can give you an idea of scale which can hint at what is being referenced.

There are, of course, security concerns with a string identifier like I mentioned, because it can give would-be attackers insight into your system.

I have even seen a blog post shunning numeric identifiers because of the impression it gives when a user is given low numbered resources (e.g. Account #5)... Not that I think this has merit. After all, you can always start your number sequence at 6-digits if user-confidence is a valid business concern. Edit: Trend analysis could be a security issue with incrementing IDs.


Is there another good reason?

Sure. There are probably many good reasons, though they may not be the reasons motivating YouTube, DailyMotion, etc:

  • The underlying resource isn't identified with a numeric key.
  • A non-numeric identifier makes casual discovery harder. That is, you can't casually browse to another resource by incrementing the key.
  • The alphanumeric string may represent more than a simple key. Who knows what's in there?
  • The alphanumeric string may represent more than a simple key. Who knows what's in there? -- what could that be?
    – Rakori
    Nov 28, 2017 at 21:31
  • 1
    @Rakori Possibly a compound key, a hashed value, or hashed values. Feb 4, 2018 at 19:06

I have always thought the reasoning was twofold and quite simple:

  • It's short enough to be typed manually if needed
  • Using uppercase/lowercase plus numbers and dashes means they will never run out of identifiers

Siebel uses a similar approach in their CRM system.

This Stack Overflow answer has a good discussion on the topic.

So basically each youtube ID is actually a 64bit number. And I quite doubt they will ever run out of those.

64 bits is enough for each human on earth to upload 2 billion videos

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.