Developer Tools·4 min read

How UUID v4 Works: Random Bits and Collision Math

Ask how a version 4 UUID works and you'll usually hear that it's random. True, but the interesting part is how random, and what the format actually guarantees. A v4 identifier packs 122 random bits into 36 characters, enough that two machines can mint keys independently for centuries without producing a duplicate. This article breaks down the version and variant bits, walks through a real generated value, puts honest numbers on collision risk, explains when a time-ordered v7 ID fits better, and lists the mistakes that turn a good identifier scheme into a support ticket.

Open the free UUID Generator All insights

Database keys without a central counter

Why random identifiers exist at all.

Auto-increment keys assume one authority hands out numbers in order. That assumption dies the moment records get created in two places at once: a mobile app writing rows offline, three service replicas inserting concurrently, or a merge between databases that each started counting from 1.

Version 4 identifiers remove the coordination entirely. Any process, on any machine, can create an ID on the spot and be statistically certain nobody else has ever produced it. That's the whole trick: replace agreement with overwhelming improbability.

How UUID v4 works, bit by bit

A UUID holds 128 bits, printed as 32 hex characters in the familiar 8-4-4-4-12 grouping. In version 4, six of those bits are fixed. Four version bits are set to 0100, which is why the third group always starts with a 4, and two variant bits are set to 10, which makes the fourth group start with 8, 9, a, or b. The other 122 bits are pure randomness.

Where that randomness comes from matters. The UUID Generator calls crypto.randomUUID() where the browser allows it, and otherwise fills the bytes with crypto.getRandomValues(). Both draw from the operating system's cryptographically secure generator. Homemade versions built on Math.random() produce the same shape with far weaker guarantees, and weak randomness is how collisions actually happen in practice.

Reading a real generated value

Here's one straight out of the generator: f60deef2-15ee-40ca-86e9-07db78f155e0. The third group, 40ca, starts with the version digit 4. The fourth group, 86e9, starts with 8, one of the four variant markers. Every other character is random hex.

Notice what's absent. Unlike version 1, nothing encodes a timestamp, a MAC address, or a sequence number, so the value reveals nothing about when or where it was created. Two v4 identifiers can't be ordered by creation time, which is a feature for privacy and a limitation for indexing.

UUID collision probability, with actual numbers

With 122 random bits there are about 5.3 times 10 to the 36th possible values. Collision risk follows birthday math: you reach a 50 percent chance of a single duplicate only after generating roughly 2.7 quintillion identifiers.

To make that concrete, a system producing one billion UUIDs every second would need about 86 years of continuous output to hit those odds. Real-world duplicates almost never come from the math. They come from broken random sources, cloned virtual machines seeding identical state, or plain copy-paste in a fixture file.

When v7 is the better choice

Random keys have one real cost: new rows land at random spots in a B-tree index, which hurts insert speed and cache use on large tables. Version 7, defined in RFC 9562, fixes that by putting a 48-bit Unix timestamp in milliseconds at the front and filling the rest with random bits. IDs created later sort later, so inserts append near the end of the index.

Set Version to v7 (time-ordered) in the generator, choose how many you need, from 1 to 10,000, and click Generate. A batch made in the same millisecond is sorted so it stays in ascending order. Copy all puts the whole list on your clipboard, one per line, and each row has its own Copy button. The trade-off is that a v7 ID reveals roughly when it was created, so keep v4 for IDs that end up in public URLs where that matters.

UUID vs GUID: two names, one format

GUID is simply Microsoft's name for the same 128-bit identifier, now specified in RFC 9562, which replaced RFC 4122. SQL Server's uniqueidentifier column, .NET's Guid.NewGuid(), and crypto.randomUUID() in a browser all speak the same string format and interoperate without conversion.

The historical wrinkle is byte order: some older Windows APIs stored the first three groups little-endian internally. As long as you exchange identifiers as strings, which is what nearly every API does, the distinction never surfaces.

Mistakes that undermine random identifiers

Watch for these when UUID keys enter a codebase:

Validating with a pattern that accepts any 36 characters, letting malformed IDs slip through where a strict check would catch them.
Generating from Math.random() in older polyfills, trading cryptographic randomness for convenience.
Expecting v4 rows to sort by creation time. Random keys scatter across an index; if insert order matters, use v7.
Truncating to the first 8 characters for readability, which quietly collapses 122 bits of safety into 32.
Treating a UUID as a secret. They're unguessable, but they leak into URLs, logs, and analytics, so never let one be the only thing protecting a resource.

Tips for shipping UUID keys in production

Store them in a native uuid or binary(16) column rather than varchar(36). The text form costs more than double the space, and that overhead multiplies across every index that references the key.

Normalize casing to lowercase at your API boundary so string comparisons never miss, and consider generating the ID on the client at record-creation time. That makes retries idempotent: the same ID resubmitted is an update, not a duplicate row.

When a UUID is the wrong shape

If you need the same input to always produce the same identifier, randomness works against you. Use the Hash Generator instead, since a digest of the content gives you a deterministic, repeatable ID.

And when you need to check whether strings claiming to be v4 identifiers really are, the Regex Tester will confirm a pattern like ^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ against your sample data in seconds.