UUID Generator
Generate up to a thousand cryptographically random UUIDs at once — version 4 or the time-ordered version 7 — and inspect any UUID to read its version, variant and timestamp.
Photo by Taylor Vick on Unsplash
UUID generator
Inspect a UUID
Key takeaways
- Version 4 gives 122 random bits; version 7 embeds a millisecond timestamp so identifiers sort in creation order.
- Use v7 for database primary keys to keep B-tree inserts sequential, and store as 16 binary bytes rather than a 36-character string.
- Collisions are a random-source problem, not a probability problem — never build a UUID from Math.random().
What a UUID is
A UUID is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12. The point of the format is that any party can mint one at any time, with no coordination, and the probability of a collision with any other UUID ever generated is negligible.
That property is what makes UUIDs so useful in distributed systems. A client can create an identifier before the record reaches the database, offline clients can generate IDs that will not clash on sync, and merging two datasets never requires renumbering. The current specification is RFC 9562, published in May 2024, which replaced RFC 4122 and added versions 6, 7 and 8.
Two bits are reserved for the variant and four for the version, leaving 122 bits of payload in a version 4 UUID.
Which version to use
| Version | Source of uniqueness | Sortable? | Use when |
|---|---|---|---|
| v1 | Timestamp + MAC address | Poorly | Legacy. Leaks the machine's MAC address. |
| v3 / v5 | MD5 / SHA-1 hash of a name in a namespace | No | Deterministic IDs derived from a stable name, e.g. a URL. |
| v4 | 122 random bits | No | The default choice for general-purpose identifiers. |
| v6 | v1 with the timestamp reordered | Yes | Migrating existing v1 data to something sortable. |
| v7 | 48-bit Unix millisecond timestamp + 74 random bits | Yes | Database primary keys. The best modern default. |
| v8 | Entirely implementation-defined | Depends | Custom schemes that still need to look like a UUID. |
Version 4 is the safe general answer. Version 7 is the better answer when the UUID will be a database primary key, for the reason below.
How safe is “probably unique”?
Version 4 has 122 random bits, giving 2122 ≈ 5.3 × 1036 possible values. By the birthday bound, you would need to generate about 2.7 × 1018 UUIDs before reaching a 50% chance of any collision.
Concretely: generating a billion UUIDs per second, it would take roughly 86 years to reach a one-in-a-billion chance of a single duplicate. For any realistic application the risk is not the maths — it is a weak random number source.
This is the failure mode that actually happens. A UUID built from Math.random() is not cryptographically random and has produced real collisions in production systems. This generator uses crypto.getRandomValues(), which draws from the operating system’s CSPRNG. Related reading: entropy and randomness.
UUIDs as database primary keys
The classic objection to UUID primary keys is index fragmentation. B-tree indexes are ordered, and inserting random keys scatters writes across the whole index instead of appending to the end. On InnoDB, where the primary key is the physical row order, this causes page splits and measurable slowdown on high-volume inserts.
Version 7 solves this. Its first 48 bits are a Unix millisecond timestamp, so UUIDs generated in time order also sort in lexical and binary order. Inserts append to the end of the index, exactly like an auto-increment key, while keeping every distributed-generation benefit.
| Concern | Auto-increment | UUID v4 | UUID v7 |
|---|---|---|---|
| Storage | 4–8 bytes | 16 bytes binary / 36 as text | 16 bytes binary |
| Insert locality | Sequential | Random | Sequential |
| Client-side generation | No | Yes | Yes |
| Leaks row count | Yes | No | No |
| Leaks creation time | No | No | Yes, to the millisecond |
Always store UUIDs in a native 16-byte type (uuid in PostgreSQL, BINARY(16) in MySQL). Storing them as CHAR(36) more than doubles the index size for no benefit.
Generating UUIDs in code
// Browser and Node 19+ — v4, cryptographically random
const id = crypto.randomUUID();
// Node.js
import { randomUUID } from 'node:crypto';
// PostgreSQL 13+
SELECT gen_random_uuid();
// Python
import uuid; str(uuid.uuid4())
// Java
UUID.randomUUID().toString();
// Go
// github.com/google/uuid
uuid.NewString()crypto.randomUUID() is available in every current browser and requires a secure context (HTTPS or localhost). Version 7 is not yet in the standard library of most languages, so it usually needs a small helper or a library.
Frequently Asked Questions
What is a UUID?
A 128-bit identifier written as 32 hexadecimal digits in the 8-4-4-4-12 pattern. It can be generated independently by any party with negligible risk of collision, which is why it suits distributed systems.
Are UUIDs really unique?
Not guaranteed, but the probability is negligible. You would need roughly 2.7 quintillion version 4 UUIDs before a 50% chance of any collision. The practical risk comes from weak random sources, not from the maths.
What is the difference between UUID and GUID?
They are the same 128-bit concept. GUID is Microsoft's name for it and is usually written in braces with uppercase hex. Microsoft GUIDs also use a distinct variant bit pattern.
Should I use UUID v4 or v7?
Use v7 for database primary keys, because its embedded timestamp keeps index inserts sequential. Use v4 for tokens, correlation IDs and anywhere you do not want to reveal when the value was created.
Can UUIDs be used as security tokens?
A v4 UUID has 122 bits of randomness, which is enough entropy for a session token, but only if generated from a CSPRNG. Never use v1 or v7 as a secret — both embed a predictable timestamp.
Do UUIDs slow down databases?
Random UUIDs (v4) fragment B-tree indexes and slow bulk inserts. Version 7 removes that problem by being time-ordered. Always store them as a 16-byte binary type rather than a 36-character string.
Is crypto.randomUUID() available everywhere?
It is supported by all current browsers and Node 19 or later, but requires a secure context. This tool builds UUIDs from crypto.getRandomValues() so it works in older environments too.
Sources & further reading
- RFC 9562 — the current UUID specification, including versions 6, 7 and 8
- MDN: crypto.randomUUID — the browser-native v4 generator
- PostgreSQL: UUID type — native 16-byte storage and generation functions
- The birthday problem — the maths behind UUID collision probability