What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value rendered as a 36-character string like 550e8400-e29b-41d4-a716-446655440000. The format and the version semantics are defined by RFC 4122 for v1 through v5, and by RFC 9562 for the newer v6, v7, and v8 versions. This tool generates v4 (purely random), v1 (timestamp plus random node ID), and v7 (Unix-millisecond timestamp prefix plus random suffix, sortable by generation time) — all in your browser, using the platform's Web Crypto API. No data is sent to a server.
How does UUID generation work?
Each version trades off determinism, sortability, and entropy differently. The tool picks the right algorithm based on your selection:
- v4 (random) calls the browser's
crypto.randomUUID(), which returns 122 bits of cryptographic randomness with the 6 fixed bits (version0100and the10variant) set in the right positions. Collisions are astronomically unlikely — you would need to generate roughly 2.71 quintillion v4 UUIDs to hit a single duplicate with 50% probability. - v1 (timestamp + node) packs a 60-bit Gregorian timestamp (100-nanosecond ticks since 1582-10-15) into
time_low/time_mid/time_hi_and_version, sets the version nibble to0001, picks a 14-bit clock sequence with the variant bits set, and uses a random 48-bit node ID with the multicast bit forced on (RFC 4122 §4.5 explicitly permits a random node ID when no hardware MAC is available — the multicast bit tags it as non-MAC). - v7 (sortable timestamp), per RFC 9562 §5.7, lays out a 48-bit big-endian Unix-millisecond timestamp, then the 4-bit version
0111, then 12 random bits, then the 2-bit variant10, then 62 more random bits. Because the timestamp is in the most-significant bits, v7 UUIDs sort lexicographically in generation order — a property no other UUID version offers without extra encoding. - All randomness comes from
crypto.getRandomValues(), the browser's cryptographically-secure RNG. Both v1 and v7 include an intra-tick monotonic guard so two consecutive calls within the same clock tick still sort the second above the first — important for bulk generation runs that race the millisecond clock. - The format pipeline runs after generation. You can strip hyphens, switch to uppercase, wrap the value in braces (
{…}— the Microsoft GUID convention), or render the raw 16 bytes as base64 (22-character output, no padding). Base64 mode overrides the other format options because base64 is its own representation.
Why use this UUID generator?
- Nothing leaves your browser. The Web Crypto API runs locally; the page makes zero network requests after the initial document load. Open DevTools, click Generate, and the Network panel stays silent.
- RFC-correct output. v4 follows RFC 4122 §4.4, v1 follows §4.2 and §4.5, and v7 follows RFC 9562 §5.7. The version nibble and variant bits are placed where the standards say they belong — every UUID validates against the canonical version regex.
- Sortable v7 for database keys. A v7 UUID used as a clustered primary key in Postgres, MySQL, or SQL Server keeps inserts append-only on the index — no page splits, no random I/O — while still being globally unique. v4 cannot do this because its bits are random.
- Bulk generation without rate limits. Generate 1, 10, 100, or 1,000 UUIDs at once. There is no quota and no signup — the tool runs in your tab, so the cap is your CPU, not a vendor's API tier.
What are common applications of UUIDs?
UUIDs show up wherever a system needs a globally-unique identifier without coordinating with a central authority:
- Database primary keys. Auto-incrementing integers leak row counts and break sharding. UUIDs are stable across shards, safe to merge across regions, and (with v7) keep B-tree inserts hot without page splits. A typical application generates the UUID client-side, sends it in the insert, and never has to round-trip the server for the key.
- Request correlation IDs. HTTP middleware attaches a v4 UUID to every incoming request, logs it on every span, and propagates it downstream (often as the
X-Request-Idheader). When a customer reports a bug, the support engineer pastes the ID and the entire request trace surfaces — across services and time zones — without ambiguity. - Idempotency keys. Payment APIs (Stripe, Adyen, Square) accept an
Idempotency-Keyheader so a retried request never charges the customer twice. A client-generated UUID guarantees the key is unique per logical operation, which is the contract those APIs require.
What does a UUID example look like?
In Node.js or a modern browser, the one-liner crypto.randomUUID() returns a fresh v4 UUID — for example 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12. Use that for a request ID or an idempotency key. When the UUID is going into a database column that will be the clustered primary key, generate v7 instead: two v7 values produced one millisecond apart, like 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 and 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4, sort lexicographically in generation order. Postgres' uuid type stores both versions identically — the difference shows up at index-write time, where v7 inserts append at the right of the B-tree while v4 inserts scatter and force random I/O.
This UUID Generator does one job: turn a click into one or many RFC-compliant identifiers, formatted the way you need them, without sending your request to a server. Pick a version, pick a count, pick a format — generate, copy, move on.