UUID Generator Online

What is a UUID, exactly?

A UUID is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12. Not all 128 bits are random. Four bits encode the version and two encode the variant, which leaves a version 4 UUID with 122 bits of randomness.

You can read the version straight off the string. The 13th hex digit is the version number, so every v4 UUID has a 4 there. The 17th digit is the variant and will be 8, 9, a, or b for the standard layout. In 550e8400-e29b-41d4-a716-446655440000 those are the 4 opening the third group and the a opening the fourth.

The current specification is RFC 9562, published in May 2024, which replaced the long-standing RFC 4122 and added versions 6, 7, and 8. Plenty of blog posts still cite RFC 4122 as current. It isn't.

Will two UUIDs ever collide?

In practice, no — but the reason is worth understanding rather than taking on faith. With 122 random bits there are roughly 5.3 × 10³⁶ possible v4 UUIDs. By the birthday bound, you would need to generate about 2.7 quintillion (2.7 × 10¹⁸) of them before reaching a 50% chance of a single duplicate. Generate 103 trillion UUIDs and your odds of any collision are about one in a billion.

That guarantee rests entirely on the randomness being good. A v4 UUID built from Math.random() — which a lot of copy-pasted snippets still do — is not cryptographically random, and its real collision resistance is far worse than the math above suggests. Use a CSPRNG: crypto.randomUUID() in browsers and Node, uuid.uuid4() in Python, uuid_generate_v4() in Postgres.

One gotcha that bites people on local networks: crypto.randomUUID() only exists in a secure context. It works on HTTPS and on localhost, but it is undefined if you load your dev server over plain HTTP at, say, http://192.168.1.20:3000. The failure looks like a missing function, not a security error, which sends people down the wrong debugging path.

UUID v4 or UUID v7 for a database key?

This is the decision that actually matters, and v4 is usually the wrong answer for a primary key.

A v4 UUID is uniformly random, so consecutive inserts land in unrelated places in the index. In MySQL's InnoDB the primary key is the clustered index — the table is physically stored in primary key order — so random keys force the engine to insert into the middle of pages it has to fetch and split, instead of appending to the tail. Write throughput drops, pages end up half-full, and your buffer pool churns because the hot set is the whole index rather than its right edge. PostgreSQL is less severe since its tables are heaps, but its B-tree index still loses the cache locality a sequential key gives you.

UUID v7 fixes this. It puts a 48-bit Unix millisecond timestamp in the leading bits and fills the rest with randomness, so v7 values generated over time sort in roughly creation order. Inserts append near the right edge of the index like an auto-increment key, while you keep the ability to generate IDs on any client without coordinating with the database. It is the same 128-bit format, so it drops into any column that already holds a UUID.

The trade-off is that v7 deliberately leaks creation time — anyone holding the ID can read the millisecond it was minted. For a row ID that is almost always fine and often useful. For an ID you hand to untrusted users where creation time is sensitive, stay with v4. (ULID solves the same ordering problem and predates v7, but now that v7 is standardised there is little reason to reach for a non-RFC format.)

Storing UUIDs without wasting space

The most common and most expensive mistake is storing a UUID as CHAR(36). That is the hyphenated text form: 36 bytes to hold 16 bytes of information, plus a character-set collation on every comparison.

In PostgreSQL use the native uuid type, which stores 16 bytes. In MySQL use BINARY(16) and convert at the boundary with UUID_TO_BIN() and BIN_TO_UUID(). The saving compounds: InnoDB appends the primary key to every secondary index, so a 20-byte-per-row overhead multiplies across each index on the table.

Two smaller details. UUIDs are canonically written lowercase, but the spec says to accept either case on input — so compare them case-insensitively, or normalise before storing. And the all-zero value 00000000-0000-0000-0000-000000000000 is the reserved nil UUID; it is a legal UUID and a terrible sentinel, because it is exactly what an uninitialised struct serialises to. A nil UUID in production data usually means a bug, not a value.

Should a UUID ever be a secret?

A v4 UUID from a CSPRNG carries 122 bits of entropy, which is more than enough to resist guessing — a password reset token needs about 128 bits and this is close. So the entropy is not the problem. The handling is.

UUIDs are treated as identifiers throughout most stacks, which means they end up in URL paths, access logs, Referer headers, analytics pipelines, and error reports. None of that infrastructure is built to protect a secret. If you need a bearer token, generate one explicitly, mark it as sensitive, and give it an expiry. Do not promote an identifier into a credential just because it happens to be unguessable.

Also worth knowing: this concern does not apply uniformly across versions. UUID v1 derives part of its value from the host's MAC address and a timestamp, so v1 values can disclose which machine generated them and when. If you have inherited v1 IDs in a public-facing API, that is a real leak worth auditing.