What Is a UUID? UUID v4 Explained with Examples (and Collision Odds)
UUIDs are everywhere in modern software: database primary keys, API resource IDs, file names, session tokens, distributed event IDs, and more. They look like a random jumble of hex digits separated by dashes, and they let completely independent systems generate unique identifiers without ever talking to each other. This guide explains what a UUID actually is, how the popular version 4 is generated, why duplicate collisions are effectively impossible, and when a UUID is the right choice for your data.
What is a UUID?
UUID stands for Universally Unique Identifier. It is a 128-bit value, standardized by RFC 4122, designed to be unique across both space and time without any central coordinator. Microsoft's implementation is called a GUID (Globally Unique Identifier) — for everyday purposes UUID and GUID mean the same thing.
A UUID is normally written as 32 hexadecimal characters split into five groups by hyphens, in the
pattern 8-4-4-4-12:
f47ac10b-58cc-4372-a567-0e02b2c3d479
Those 32 hex characters represent 128 bits of data. The hyphens are purely cosmetic; they make the value easier to read and have no effect on its meaning.
The different UUID versions
There is more than one way to produce a UUID, and the "version" tells you how it was generated. The version number is encoded in the 13th hex digit (the first character of the third group).
| Version | Based on | Typical use |
|---|---|---|
| v1 | Timestamp + MAC address | Time-ordered IDs (leaks the machine) |
| v3 / v5 | Hash of a name + namespace | Deterministic IDs from known input |
| v4 | Random numbers | General-purpose unique IDs (most common) |
| v7 | Unix timestamp + random | Sortable, database-friendly IDs (newer) |
By far the most widely used is version 4, the random UUID. It is what most libraries and the UUID Generator produce by default.
How UUID v4 works
A version 4 UUID is almost entirely random. Of its 128 bits, 122 are filled with random data, and only 6 bits are fixed to mark the version and the variant. Concretely:
- The version field is set so the 13th hex digit is always
4 - The variant field is set so the 17th hex digit is always one of
8,9,a, orb - Every other digit is random
You can spot a v4 UUID by eye using those two markers:
f47ac10b-58cc-4372-a567-0e02b2c3d479
│ │
version 4 variant
Because generation is purely local and random, two servers on opposite sides of the world can each mint UUIDs at the same instant with no coordination and still never clash.
What are the odds of a collision?
This is the question everyone asks: if v4 is random, could two be the same by accident? In theory yes; in practice no. With 122 random bits there are about 5.3 × 1036 possible values. To put that in perspective, you would need to generate roughly 1 billion UUIDs per second for about 85 years before the probability of a single collision reached even 50%.
For any realistic application, the chance of generating a duplicate is so small that it is treated as effectively zero. You are far more likely to lose data to a hardware failure than to a UUID collision. The one caveat: this assumes a good source of randomness. A broken or predictable random number generator can undermine those odds, which is why secure libraries use cryptographic randomness.
UUID vs auto-increment IDs as database keys
A classic design decision is whether to use UUIDs or simple auto-incrementing integers (1, 2, 3, …) as primary keys. Both have trade-offs.
Advantages of UUIDs
- Clients and distributed services can generate IDs independently, before talking to the database
- They do not leak counts (an integer ID of 5,000 tells a competitor how many records you have)
- They make merging data from multiple databases far easier
- They are hard to guess, reducing trivial ID-enumeration attacks
Disadvantages of UUIDs
- They are larger (16 bytes vs 4–8 for integers), which grows index size
- Random v4 values are not sortable and can hurt write performance on clustered indexes
- They are harder for humans to read, type, and compare
If you need both uniqueness and time-ordering for database performance, the newer UUID v7 (timestamp-prefixed) is increasingly recommended because it sorts naturally while keeping the distributed-generation benefits.
Common uses for UUIDs
- Primary keys and foreign keys in databases
- Resource identifiers in REST APIs (
/users/f47ac10b-…) - Idempotency keys to safely retry API requests
- Unique file names to avoid overwrites in object storage
- Correlation IDs for tracing a request across microservices
When you need many at once — for seeding a database, load testing, or generating sample data — a bulk generator saves time. Try the UUID Bulk Generator to produce and download hundreds at once.
Generate UUIDs and related values
These browser-based tools create identifiers instantly and keep everything local to your device:
Conclusion
A UUID is a 128-bit identifier you can generate anywhere, by anyone, with essentially no risk of collision. Version 4 fills almost all of those bits with randomness, which is why independent systems can safely mint their own IDs. Use UUIDs when you need decentralized, hard-to-guess, merge-friendly identifiers, weigh their size and ordering costs against integer keys, and consider v7 when you also need database-friendly sorting.
Frequently Asked Questions
Is a UUID the same as a GUID?
Yes, for practical purposes. GUID is Microsoft's name for the same 128-bit identifier defined by the UUID standard.
Can two UUID v4 values ever be the same?
It is theoretically possible but practically impossible. With 122 random bits, the probability of a collision is so small it is treated as zero for real applications.
How can I tell which version a UUID is?
Look at the 13th hex digit (the first character of the third group). A value of 4 means it is a version 4 UUID.
Should I use a UUID as a database primary key?
It depends. UUIDs allow decentralized generation and hide record counts, but they are larger and random v4 values can hurt index performance. UUID v7 offers a sortable compromise.
Are UUIDs secure or secret?
They are hard to guess but should not be treated as secrets or passwords. Use them as identifiers, not as authentication tokens on their own.