UUID generator
Generate version 4 (random) or version 7 (time-ordered) UUIDs, one at a time or up to a thousand at once. Every UUID is produced in your browser using the Web Crypto API — what you generate never leaves your device.
Generate UUIDs
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value, almost always written as 32 hexadecimal digits split into five groups — 8-4-4-4-12 — separated by hyphens, for example 2f1e9c3a-7b6d-4e12-9a3c-5d8f0b1e2a44. The format is defined by RFC 9562, published by the IETF in May 2024, which obsoletes the older RFC 4122 and adds several new UUID versions on top of it, including version 7.
The point of a UUID is to let independent systems — different servers, different services, different developers who have never spoken to each other — each generate identifiers without a shared counter or a central authority, while the chance of two of them ever producing the same value stays low enough to treat as zero for any practical purpose. That is what makes UUIDs useful for database primary keys, request IDs, session tokens, file names and distributed-system correlation IDs.
v4 vs v7
Both versions are 128 bits with the version and variant nibbles occupying the same fixed positions. Where they differ is what fills the rest of the bits.
v4 — pure randomness
122 bits of cryptographically random data, with no other structure. Two v4 UUIDs generated a millisecond apart, a year apart, or by two completely different machines are statistically indistinguishable from each other — nothing in the identifier reveals when or where it was created. That is a genuine privacy property: a v4 UUID leaks no timing metadata.
v7 — time-ordered
The first 48 bits are a Unix timestamp in milliseconds, so a v7 UUID generated later always sorts after one generated earlier when the two are compared as plain strings or bytes — the same property a database auto-increment integer has, but without needing a shared counter. This is called index locality: relational databases store rows for a table's primary key in roughly index order on disk, and when new keys are also roughly ascending, new rows land near the end of the index rather than at a random position inside it. Random keys like v4 scatter new rows across the whole index instead, which tends to mean more page splits and worse cache behaviour as a table grows. v7 was standardised specifically to give UUIDs the sortability that made auto-increment integers convenient for indexing, without giving up global, coordination-free uniqueness.
The trade-off is symmetric. v7's timestamp is exactly the information v4 deliberately withholds. If revealing approximately when a record was created is a problem for your use case — a password-reset token, say, where you would rather not leak issuance time — v4 is the more conservative choice.
Anatomy of a UUID: version and variant bits
Every UUID, regardless of version, reserves two fixed positions so software can identify what kind of UUID it is looking at without any external context:
| Field | Position | Meaning |
|---|---|---|
| Version nibble | 15th character | First character of the third group. One hex digit identifying the UUID version — 4 for v4, 7 for v7. |
| Variant bits | 20th character | First character of the fourth group. Its top two bits are fixed at 10, so this character is always 8, 9, a or b for the RFC 9562 variant this generator produces. |
| v4: everything else | 122 bits | Cryptographically random, drawn fresh for every UUID. |
| v7: bits 0–47 | First 12 hex characters | Unix timestamp in milliseconds, big-endian. |
| v7: remaining bits | 74 bits | Cryptographically random, drawn fresh for every UUID. |
These fixed positions are why every UUID this tool generates has the recognisable …-4…-… or …-7…-… shape, and why the inspector further down can identify a pasted UUID's version and variant without any other information about where it came from.
How likely is a collision, really?
Not mathematically impossible — the space is finite — but far below any threshold worth worrying about in ordinary use. A v4 UUID has 122 random bits, so there are 2122 ≈ 5.3 × 1036 possible values. Using the standard birthday-bound approximation n ≈ √(2N ln 2), you would need to generate roughly 2.7 × 1018 (2.7 quintillion) version-4 UUIDs before there is even a 50% chance that any two of them coincide.
To put that in perspective: generating one billion UUIDs every second, continuously, it takes about 86 years to reach that 50% mark for a single collision anywhere in the entire set you generated. Almost nothing generates identifiers at that rate. In practice, reported UUID collisions trace back to a broken or predictable random source, a bug that reuses the same seed, or copy-paste of a hard-coded value — not to the birthday math catching up with a correctly implemented generator.
v7 does not change this calculation for the random portion: only 74 of its 128 bits are random rather than v4's 122, so the birthday-bound number for a pure v7 collision is smaller in absolute terms, but a v7 collision additionally requires the same random bits and the same millisecond timestamp, which is a much stricter condition in practice for any real generation rate.
When to use which
| Situation | Prefer | Why |
|---|---|---|
| High-write relational database primary key | v7 | Timestamp ordering keeps new rows near the end of the index, reducing page splits. |
| Password-reset or invite token | v4 | No timing information leaked about when the token was issued. |
| Log line / request correlation ID | v7 | Sorting by ID roughly sorts by time, which is convenient when scanning logs. |
| Anything already keyed by an existing timestamp column | v4 | The time information is already stored elsewhere; no benefit to duplicating it in the key. |
| Public-facing resource identifiers (API URLs, filenames) | v4 | Avoids revealing approximately when a resource was created via its URL. |
| New system with no existing UUID column to stay consistent with | v7 | It is the version RFC 9562 was extended to add specifically for this case. |
Identify an existing UUID
Paste any UUID — hyphens optional — to read back its version and variant using the fixed positions described above.
Worked examples
Three version-4 UUIDs, each independent of the others:
17b7a6a0-4179-4445-bf09-3380b97cdd87
a4838873-7cb9-47de-be7a-f91a534b08ff
1e2b9f2c-5e29-4bca-bb7e-167a91359455
Notice the 15th character (the start of the third group) is always 4, and the 20th character (the start of the fourth group) is always in the 8–b range the variant requires — here it lands on b all three times, which is coincidence, not a rule. Nothing else about the three strings has any relationship to each other.
Three version-7 UUIDs generated three milliseconds apart:
019fa2db-9f50-7df6-83dd-1cdef4f37a89
019fa2db-9f53-764b-ac3e-496710061a9e
019fa2db-9f56-7889-857c-095a5968ba1e
The first 11 characters are identical — that is the shared millisecond-scale timestamp prefix, since all three were generated within the same few milliseconds — and the three strings sort in exactly the order they were generated, which is the entire reason to reach for v7 over v4 for a key you plan to index or scan chronologically.
Frequently asked questions
Are the UUIDs generated here truly random?
The random bits come from the Web Crypto API — crypto.getRandomValues, or crypto.randomUUID directly where the browser supports it — which draws from the operating system's cryptographically secure random number generator. That is a materially different (and much stronger) source than Math.random, which is not specified to be unpredictable and should never be used to generate identifiers.
What is the actual difference between UUID v4 and v7?
A v4 UUID is 122 bits of randomness with a fixed version and variant marker and no other structure — generating one twice a millisecond apart gives no clue which came first. A v7 UUID replaces the first 48 bits with a millisecond-resolution Unix timestamp, so UUIDs generated later sort after ones generated earlier when compared as plain strings. The trade is that a v7 UUID reveals approximately when it was created; a v4 UUID reveals nothing at all.
Can two UUIDs ever actually collide?
The space is finite, so a collision is not mathematically impossible. For v4, the random part is 122 bits, giving about 5.3 × 1036 possible values. Using the standard birthday-bound approximation, you would need to generate roughly 2.7 × 1018 (2.7 quintillion) version-4 UUIDs before there is even a 50% chance that any two of them match. Generating one billion a second, that is about 86 years of continuous generation for a coin-flip's chance of one single collision anywhere in the whole set. In practice, collisions are dominated by implementation bugs — a broken random source, or accidentally reusing a seed — not by the birthday math.
Why does this tool only offer v4 and v7, not v1, v3, v5, v6 or v8?
v4 and v7 cover the two situations that come up in practice: pure random identifiers, and time-ordered ones for database keys. v1 embeds the generating machine's MAC address and a timestamp, which is a real privacy leak and is now generally discouraged. v3 and v5 are deterministic namespace hashes (MD5 and SHA-1 respectively) of an input you supply — useful for a specific job, but not a “generate me an ID” tool, since the same input always produces the same output. v6 is a field-reordered variant of v1's timestamp aimed at sort order without the MAC address, but v7 has become the practical default for new systems wanting a sortable UUID. v8 has no defined internal layout at all — it exists purely so organisations can define their own custom format inside a standard UUID envelope, which is out of scope for a general-purpose generator.
Is a UUID the same thing as a GUID?
In current practice, yes — GUID is Microsoft's name for the same 128-bit identifier format the UUID specification defines, and current Windows and .NET tooling generates standard RFC-variant UUIDs. The one historical wrinkle is that some very old COM-era GUIDs used a different, pre-standard variant bit pattern rather than the 10xx variant this generator produces; that is one of the reasons the variant field exists at all, and why the inspector above reports it separately from the version.
Why is there always a 4 or a 7 in the same position?
That character is the version nibble, fixed by the specification at the first character of the third group in the standard 8-4-4-4-12 layout — the 15th character overall, counting hyphens. It is set to 4 or 7 (or another digit for a different version) on every UUID of that version, on purpose, so software can tell at a glance which generation rule produced an identifier.
Do you store or log the UUIDs I generate?
No. Generation happens entirely in your browser — there is no server call involved in producing a UUID, so nothing you generate is uploaded or recorded anywhere by this page. Copying, downloading and pasting into the inspector all stay on your device too.
Should I use v4 or v7 as my database primary key?
For a high-write relational table, v7 is usually the better default: because new values are timestamp-ordered, they insert near the end of a B-tree index rather than at random positions throughout it, which reduces page splits and keeps recently-inserted rows physically close together — closer to the behaviour of an auto-incrementing integer key, while still being globally unique without coordination. v4 remains a reasonable choice for lower-volume tables, or specifically when you do not want an identifier to reveal roughly when the row was created.
Use cases & limitations
Where this is genuinely useful
- Database primary and foreign keys where you want global uniqueness without a central sequence — pick v7 for write-heavy tables, v4 where creation-time privacy matters more than index locality.
- Seed data and fixtures for tests and demos — generate a batch of a thousand at once and paste them straight into a SQL script or JSON fixture with the quoted, comma-separated option.
- Request and trace correlation IDs for logs and distributed tracing, where v7's rough time-ordering makes scanning a log chronologically by ID convenient.
- One-off tokens — API keys, invite codes, session identifiers — where v4's lack of embedded timing information is the safer default.
- Learning the format — the inspector lets you paste any UUID you already have and see exactly which bits mean what.
What this tool does not do
- No v1, v3, v5, v6 or v8 generation. Only v4 and v7, deliberately — see the FAQ above for why.
- No cryptographic signing or embedded metadata beyond the version 7 timestamp. A UUID is an identifier, not a credential; do not rely on one being unguessable in a security context without additional protection, and do not encode secret information inside one.
- No persistence. Nothing you generate is saved by this page. Copy, download, or lose it when you navigate away — there is no history to come back to.
- No verification that a pasted UUID was generated correctly by whatever produced it. The inspector reads the version and variant nibbles exactly as they appear; a string can be crafted to claim any version without actually having been produced by that algorithm.