UUID v4 Explained: How Random IDs Avoid Collisions

A UUID (Universally Unique Identifier) is a 128-bit value written as 32 hexadecimal digits in five groups, like 3f2b8c1e-9a4d-4e7b-8c21-5d6f0a1b2c3d. The interesting question is not what it looks like but how something generated on your laptop, with no central server and no coordination, can be trusted not to collide with one generated on someone else's machine a year later.

This guide explains how version 4 works, how safe it really is, where it is the wrong tool, and how to generate a batch in your browser.

How a UUID v4 is built

Count the characters in the example: eight, four, four, four, then twelve, separated by hyphens. That is 32 hex digits, or 128 bits. In a version 4 UUID, six of those bits are fixed:

• The first digit of the third group is always 4. That is the version marker. In the example above it is the 4 in 4e7b.
• The first digit of the fourth group is always 8, 9, a or b. That marks the variant (the standard layout). In the example it is the 8 in 8c21.

The other 122 bits are random. There is no counter, no timestamp, no MAC address and no machine name baked in, which is what separates v4 from older versions. Two v4 UUIDs created a millisecond apart on the same machine are unrelated to each other.

Why collisions are not a practical worry

122 random bits means 2^122 possible values, roughly 5.3 x 10^36. By the birthday-paradox math, you would need to generate about 2.7 x 10^18 UUIDs, around 2.7 quintillion, before the chance of any pair colliding reaches 50 percent. At a billion UUIDs per second, that is around 85 years of continuous generation.

So when duplicates do appear in a real system, the cause is almost never bad luck. It is a weak random source (an old library seeded with the clock), a copied value, a restored backup replayed twice, or a bug that reuses one ID. Check those before blaming probability.

How to generate UUIDs

1. Open the UUID Generator.
2. Move the slider to the number you need, from 1 up to 50.
3. Generate the list. Each value comes from the browser's crypto.randomUUID(), a cryptographically secure source.
4. Copy the values into your seed file, test fixtures or spreadsheet.

If you need more than 50, generate in batches or use the same call in code: crypto.randomUUID() is built into modern browsers and Node.

Benefits of random IDs

• No coordination. Any service, mobile app or offline client can mint an ID without asking a database for the next number. That makes merging data from several sources far simpler.
• No information leak. A sequential ID like /orders/1042 tells a visitor roughly how many orders you have and invites them to try 1041. A random ID does not.
• Safe to create early. A client can generate an ID before the record is saved, then use it in related records and retries without waiting for the server.
• Uniform format. Every system recognizes the 8-4-4-4-12 shape, so validation and logging are straightforward.

When a UUID is the wrong choice

Random v4 UUIDs are not free. Be honest about the costs:

• Index locality. A random key scatters new rows across a B-tree index instead of appending them at the end. On large tables with a clustered primary key, that increases page splits and can slow inserts. A timestamp-ordered scheme or a plain auto-increment integer behaves better here. Newer UUID versions that put a timestamp first (such as version 7, defined in RFC 9562) exist for exactly this reason.
• Storage size. A UUID is 16 bytes as binary, and 36 characters if stored as text. A 4-byte or 8-byte integer is smaller, and every secondary index copies the key.
• Readability. Nobody reads a UUID over the phone. If support staff need to quote an ID, a short human-friendly reference code is kinder.
• Not a secret. A UUID is an identifier, not a credential. Do not treat "unguessable" as "authorized".

The deciding question is whether you need "no collisions with no coordination" or "sorts naturally by creation time". A v4 UUID solves only the first.

Where typical ID tools fall short

Many UUID generator sites work fine, but some put a generate button under a wall of ads, cap you at one value per click, or run generation on a server so the IDs travel over the network. For test data that is harmless. For anything you plan to use as a real identifier, you would rather it be created locally. The MergeDoc generator runs in your browser with no sign-up, and it is simply a front end to the same crypto.randomUUID() you would call in code, so the results are equivalent.

Everyday uses

• Seeding a development database. Generate 50 IDs for fixture rows instead of typing fake ones.
• Naming uploaded files. Rename user uploads to a UUID to avoid collisions and avoid exposing original filenames.
• Tracking correlation IDs. Paste a UUID into a request header so one transaction can be followed across logs.
• Placeholder keys in a spreadsheet or mock API response.
• Idempotency keys. Send a UUID with a payment or order request so a retry is not processed twice.

Tips and mistakes

Store UUIDs in your database's native UUID or 16-byte binary type if it has one, not as a 36-character string, to save space and speed up comparisons. Keep the case consistent: the hex digits are case-insensitive, but comparing ABC with abc as strings will fail.

Do not truncate a UUID to make it shorter. Cutting it to 8 characters leaves 32 bits, and collisions then become realistic after tens of thousands of IDs.

Never use an older UUID generator that is not clear about its random source. If a library seeds from the clock, duplicates become genuinely possible. And remember that UUIDs are not a hash of anything: if you need a fingerprint of some content, use the Hash Generator and read SHA-256 Hash Explained.

UUID versions at a glance

You will meet several versions in the wild, and knowing which is which saves confusion when you read someone else's schema.

• Version 1 combines a timestamp with a node identifier, historically the MAC address. It sorts roughly by time but can leak when and where it was generated.
• Version 3 and 5 are name-based: the same namespace and name always produce the same UUID, using MD5 (v3) or SHA-1 (v5). Useful when you need a stable ID derived from, say, a URL.
• Version 4 is random, and it is what browsers and most libraries produce by default.
• Version 7 puts a Unix millisecond timestamp first, followed by random bits, so values sort by creation time while staying unguessable in the low bits.

If you are starting a new table and you expect heavy insert volume, version 7 is worth a look, provided your language or database library supports it. If you just need a unique label for a test row, v4 is perfectly good.

Checking a UUID by eye

You can sanity-check a v4 UUID without a tool. Count 8-4-4-4-12 characters. Look at the first character of the third group: it must be 4. Look at the first character of the fourth group: it must be 8, 9, a or b. A value that fails either check was not produced by a standard v4 generator, which is a handy clue when you are debugging IDs that came from a hand-edited import.

Related reading

For another time-related identifier question, see Unix Timestamp Explained, which covers the other common way to order records. If you need unguessable secrets rather than identifiers, read Strong Passwords vs Passphrases. For debugging payloads that carry these IDs, Minified JSON Debugging helps, and the developer tools page lists everything else in this category.