A UUID (universally unique identifier) is a 128-bit value used to label things such as database rows, files and API requests, without any central authority handing out numbers. It's written as 32 hexadecimal digits in five hyphen-separated groups of 8-4-4-4-12, like 3fa85f64-5717-4562-b3fc-2c963f66afa6.
The current standard is RFC 9562, published by the IETF in May 2024, which obsoletes the older RFC 4122. Its abstract notes that UUIDs are also known as GUIDs (globally unique identifiers), the name Microsoft uses. This guide explains how to read the format, what the version and variant bits mean, which versions matter (v1, v4, v5 and v7), how small the collision odds really are, and when a plain random number is the better tool. You can make one with the UUID Generator.
The UUID format: 8-4-4-4-12
RFC 9562 defines a UUID as 16 octets, or 128 bits. Written out, each hex digit holds 4 bits, so 128 bits become 32 hex digits, and the four hyphens bring the string to 36 characters. The groups are always 8, 4, 4, 4 and 12 digits long:
3fa85f64-5717-4562-b3fc-2c963f66afa6
└──8───┘ └4─┘ └4─┘ └4─┘ └────12────┘The letters a to f may be uppercase, lowercase or mixed. The RFC treats 3FA85F64-… and 3fa85f64-… as the same UUID, so compare them case-insensitively, or normalize to lowercase before storing. Two special values are also defined: the Nil UUID, 00000000-0000-0000-0000-000000000000 (all bits zero), and the Max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff (all bits one). The RFC suggests these as sentinels, for example to mean "no value here" or to mark the end of a list.
Version and variant bits: how to read a UUID
Not all 128 bits are free. Two small fields say what kind of UUID you're looking at:
- Version (4 bits, bits 48 to 51): the first hex digit of the third group. In
3fa85f64-5717-4562-b3fc-2c963f66afa6it's4, so this is a version 4 UUID. - Variant (bits 64 and 65, set to binary 10): the first hex digit of the fourth group. Because the top two bits are
10, that digit is always8,9,aorbfor standard UUIDs. Here it'sb.
So you can identify most UUIDs at a glance: look at the 13th hex digit for the version and the 17th for the variant. In a version 4 UUID, those 6 fixed bits leave 122 random bits.
UUID versions: v1, v4, v5 and v7
| Version | Built from | Typical use |
|---|---|---|
| v1 | 60-bit timestamp (100-nanosecond intervals since 1582), clock sequence and node ID, often a MAC address | Legacy systems |
| v3 | MD5 hash of a namespace and a name | Legacy; RFC prefers v5 |
| v4 | Random or pseudorandom bits | The default almost everywhere |
| v5 | SHA-1 hash of a namespace and a name, truncated to fit | Repeatable IDs for the same name |
| v6 | v1's fields reordered so the timestamp sorts first | Systems already using v1 |
| v7 | 48-bit Unix timestamp in milliseconds, then random bits | Database keys that sort by time |
| v8 | Custom layout; only version and variant are fixed | Vendor-specific formats |
Version 1
The original time-based design. RFC 9562 warns that MAC addresses pose privacy and security risks and "SHOULD NOT be used within a UUID", and says implementations "SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible."
Version 4
122 random bits plus the version and variant markers. Browsers generate it with crypto.randomUUID(), which MDN documents as using a cryptographically secure random number generator and as available only in secure (HTTPS) contexts. Python's uuid.uuid4() and PostgreSQL's gen_random_uuid() also produce v4.
Version 5
A name-based UUID: the same namespace and name always give the same UUID. In Python, uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com") returns 2ed6657d-e927-568b-95e1-2665a8aea6a2 on every machine, every time. That's useful when two systems need to derive the same ID independently, for example from a URL. Because the output can be recomputed from the input, a v5 UUID hides nothing about the name it came from.
Version 7
New in RFC 9562. The first 48 bits are milliseconds since the Unix epoch, followed by the version digit and 74 bits that are random or partly used as a counter. Here's an example we built from the timestamp for 2025-01-01 00:00:00 UTC:
01941f29-7c00-7cde-83f1-a2b3c4d5e6f7
└─ 0x01941f297c00 = 1735689600000 ms = 2025-01-01 00:00:00 UTCA 48-bit millisecond counter runs out around the year 10889, so the field won't overflow any time soon. If the Unix timestamp part looks familiar, it's the same count JavaScript's Date.now() returns.
UUID v4 vs v7 for database keys
This is the main practical choice today. RFC 9562 says that UUID versions that aren't time ordered, such as v4, "have poor database-index locality": each new random key lands somewhere different in a B-tree index, so inserts touch scattered pages. v7 values created close together sort close together, much like an auto-increment integer.
- Choose v7 for high-volume primary keys and anything you want to sort roughly by creation time.
- Choose v4 when the ID shouldn't reveal when a record was created. Anyone can decode a v7 timestamp, as shown above. For security-related uses the RFC says "UUIDv4 SHOULD be utilized."
- Store UUIDs as binary where you can. The RFC recommends a 128-bit binary type over text where feasible: 16 bytes instead of 36 characters. PostgreSQL's
uuidcolumn type does this.
Whichever version you pick, a UUID is an identifier, not a secret. RFC 9562 says implementations "SHOULD NOT assume that UUIDs are hard to guess" and that UUIDs "MUST NOT be used as security capabilities," meaning IDs whose mere possession grants access.
How likely is a UUID collision?
With 122 random bits there are 2122, about 5.3 × 1036, possible version 4 UUIDs. The birthday-problem approximation gives the chance of at least one duplicate among n of them. This Python computes it:
import math
N = 2**122
def p_dup(n):
return -math.expm1(-n * n / (2 * N)) # 1 - e^(-n²/2N)
p_dup(1e9) # 9.4e-20
p_dup(1e12) # 9.4e-14
p_dup(1e15) # 9.4e-08
math.sqrt(2 * N * math.log(2)) # 2.71e18 UUIDs for a 50% chance- 1 billion UUIDs: about 9.4 × 10−20, effectively zero.
- 1 trillion UUIDs: about 9.4 × 10−14, roughly 1 in 10 trillion.
- A 50% chance of any duplicate takes about 2.71 × 1018 UUIDs, roughly 86 years of generating a billion every second.
For v7 the question is different, because only IDs created in the same millisecond can collide. If all 74 bits after the timestamp are random, even a million v7 UUIDs in one millisecond have about a 2.6 × 10−11 chance of a clash. These figures assume a good random source. In practice, real duplicate UUIDs come from bugs, such as a badly seeded generator or code that copies an ID instead of generating a new one, not from bad luck.
UUID vs random number: which do you need?
Both tools give you characters you didn't have to think up, so it's easy to reach for whichever is open. They solve different problems. A random number generator picks a value within a range you set, like 1 to 100, with no uniqueness guarantee at all. A UUID gives you something that won't collide with anything else, for all practical purposes, without a range.
Repeats in a small range are the likely outcome, not a bug. The chance that five draws from 1–10 are all different is (10 × 9 × 8 × 7 × 6) ÷ 105 = 0.3024, so there's about a 70% chance of at least one duplicate. Draw 12 numbers from 1–100 and it's close to a coin flip. That's the same birthday math as above, with a tiny range instead of a gigantic one. If each value must be unique, such as raffle winners or a random sample, turn on "No duplicates" in the Random Number Generator.
Not all randomness is equal
General-purpose functions such as JavaScript's Math.random() are fine for games, raffles and sampling, but MDN is explicit that it "does not provide cryptographically secure random numbers." Our Random Number Generator uses that general-purpose source, which suits its jobs. Our Password Generator uses crypto.getRandomValues(), which is the one to use when a value needs to stay secret.
How to tell which one you need
- An identifier for a database row, object, file or request: use a UUID. You need uniqueness, not a range.
- A raffle winner, dice roll or random sample: use a random number. You need a value within a defined range.
- Test fixture IDs: use a UUID, so data seeded by different developers can't collide.
- A short code a person types, like a 6-digit verification number: use a random number from 0 to 999,999 with leading zeros, generated with a secure source such as
crypto.getRandomValues(). A UUID is far too long to type. Don't treat these codes as unique: with a million possibilities, there's about a 50% chance two match once roughly 1,178 have been issued, so tie each one to a single user and let it expire quickly. - A secret, like a password-reset token or API key: use a secure generator built for secrets. A UUID is meant to be copied into logs and URLs where others can see it.
Both run entirely in your browser. Nothing is sent to a server.
UUID Generator →Frequently asked questions
What is a UUID used for?
A UUID labels something, such as a database row, file, message or API request, with an ID that is unique for all practical purposes. Because any machine can generate one without asking a central server, UUIDs suit distributed systems and data merged from many sources.
What is the difference between a UUID and a GUID?
They are the same thing. GUID, short for globally unique identifier, is the name Microsoft uses. RFC 9562, the current UUID standard, notes that UUIDs are also known as GUIDs.
How can I tell which version a UUID is?
Look at the first character of the third group. In 3fa85f64-5717-4562-b3fc-2c963f66afa6 the third group starts with 4, so it is a version 4 UUID. A 1 there means version 1, a 5 means version 5 and a 7 means version 7.
Can two UUIDs ever be the same?
In principle, yes, but for properly generated version 4 UUIDs the odds are negligible. With 122 random bits, you would need to generate roughly 2.7 × 10^18 UUIDs before the chance of any duplicate reached 50%. Real-world duplicates almost always come from software bugs rather than chance.
Should I use UUIDv4 or UUIDv7 for database keys?
UUIDv7 starts with a millisecond timestamp, so new values sort close together and tend to perform better as database index keys. UUIDv4 is fully random, which reveals nothing about when a record was created. Prefer v7 for high-volume primary keys and v4 when creation time should stay private.
Is a UUID safe to use as a password or secret token?
No. RFC 9562 says UUIDs should not be assumed hard to guess and must not be used as security capabilities, meaning IDs whose possession alone grants access. Use a secure generator built for secrets, such as one based on crypto.getRandomValues().
Is a random number generator safe for verification codes?
Only if it uses a cryptographically secure source. JavaScript's Math.random() is not designed for security, so verification codes, tokens, and passwords should come from crypto.getRandomValues() or an equivalent secure generator.