UUID Generator

A UUID is a 128-bit value written as 32 hexadecimal characters in five hyphenated groups — 8-4-4-4-12, 36 characters in all. Any process on any machine can mint one without asking a central authority for the next number, which is the whole reason they exist.

v7 → 019ff019-fdfe-7a3c-9e21-4b8d0f6c15e9 — the leading 019ff019fdfe is the Unix millisecond it was minted, so a batch comes back in the order it was made

One question decides the version: is it going in an indexed column? v7 leads with that timestamp, so inserts stay clustered at the right edge of the B-tree; v4 is 122 random bits and scatters them across the whole index; v1 is for systems that already expect it. Every value here is minted in this tab by crypto.getRandomValues — nothing is uploaded.

Auto-incrementing integers are compact and readable, but they force every writer through a single source of truth. UUIDs remove that bottleneck: a mobile client can create records while offline, a queue consumer can assign ids before the row exists, and two shards can merge without renumbering anything.

They are also safer to expose. A sequential id in a URL quietly publishes how many records you have and lets anyone walk your dataset by counting upwards. A UUID reveals neither.

The trade-offs are real and worth naming. A UUID takes 16 bytes against 8 for a bigint, and 36 bytes if you store the text form. Fully random v4 values also scatter B-tree inserts across the whole index, which hurts write throughput on large tables. v7 was standardised precisely to solve that second problem.

RFC 9562 — which superseded the long-serving RFC 4122 — defines eight versions. Two fields are fixed in every one of them: the version nibble that opens the third group, and the variant bits that open the fourth. Everything else is filled by the version's own algorithm, and three versions cover almost every real use case.

Every identifier on this page is produced by the Web Crypto API — specifically crypto.getRandomValues, the same cryptographically secure source your browser uses for TLS. There is no server call, no queue, and no fallback to Math.random.

v7 gets one extra guarantee. When several ids are minted inside the same millisecond, the twelve rand_a bits are used as a dedicated counter rather than random noise, following the monotonicity method in RFC 9562. A batch of 500 therefore comes back in strictly ascending order.

Because the work happens locally, the values you see were never transmitted, never logged, and never stored. Load the page once and it keeps working with the network switched off. The batch size is capped at 500 so a single generation stays imperceptible even on a low-powered device.

The most common use is a primary key. v7 is the better choice here: it keeps inserts clustered at the right edge of the index the way a sequence would, while still being generated by the client.

Idempotency keys are the second big one. Attach a fresh UUID to a payment or a webhook retry and the receiving service can safely discard duplicates without any shared state.

Beyond persistence, UUIDs are the default for correlation and trace ids that stitch a request together across services, for object-storage keys that must not collide between uploaders, and for seeded test fixtures where a readable, guaranteed-unique value beats a hand-written string.