~/tools/uuid

> uuid

generate uuids in your browser: v4 (random) or v7 (time-ordered). v7 is the modern choice for database primary keys; v4 is fine for everything else.

version:count:
$ output
click generate.

## overview

a uuid (universally unique identifier) is a 128-bit value typically rendered as 36 hex characters with dashes. two common versions: v4, which is 122 random bits (2 bits and a nibble are fixed for version and variant) — effectively never collides in practice; and v7, which puts a 48-bit unix millisecond timestamp at the front of the id, then 74 bits of randomness. v7 (rfc 9562, published 2024) is designed for database primary keys — id order roughly matches insertion time, which keeps b-tree indexes compact and avoids random-insertion penalties. v4 stays useful for tokens, cache keys, correlation ids, and anywhere ordering does not matter. both versions produce 36-char strings of the form xxxxxxxx-xxxx-Vxxx-yxxx-xxxxxxxxxxxx, where V is the version digit (4 or 7).

## how to use

  1. pick a versionv4 for generic random ids. v7 for anything stored in a database and used as a primary key or index.
  2. click generateone click produces one uuid. generate multiple by clicking again.
  3. copy and usecopy the result and paste into your code, database, or config.

## examples

$ example 1 — v4 — fully random
$ in
(click v4)
# out
b3f9d4f8-0a23-4a6b-a4d2-5c8a6b3f9e2a
$ example 2 — v7 — first 12 hex chars encode the unix millis; ids generated close in time share a prefix
$ in
(click v7)
# out
018ef3e5-7b12-7a9c-b4d2-5c8a6b3f9e2a
$ example 3 — collision probability is astronomically low (~2^61 generations for a 50% chance)
$ in
(click v4 twice)
# out
two different uuids

## common mistakes

  • v1 / v2 deprecatedv1 included the mac address and was deprecated for privacy. v2 is almost never used. v3 and v5 are deterministic (namespace + name hash). prefer v4 or v7 for new work.
  • v4 in indexesrandom v4 ids as primary keys cause heavy b-tree page splits, slow inserts, and fragmented indexes at scale. switch to v7 for new tables.
  • v7 privacyv7 leaks the creation timestamp (millisecond precision). if timing reveals information (account creation, event sequence), use v4 or hash-based identifiers instead.
  • case & hyphensuuids are case-insensitive hex. most tools emit lowercase. some systems store without hyphens as 32 chars — equivalent.
  • not secretsuuids are not random enough to be auth tokens on their own. use a csprng-derived token for auth.

## faq

v4 or v7?

v7 if the id is stored and indexed. v4 if it's ephemeral or used as a nonce. v7 gives you ordering plus uniqueness; v4 gives you uniqueness only.

what is the collision probability for v4?

with 122 random bits, you would need to generate ~2.7 billion uuids to hit a 50% chance of a single collision (the birthday bound). not a practical concern.

are v7 uuids sortable?

yes, lexicographically. two v7 ids compare the same way as their timestamps (and then random bits for ties within the same millisecond).

does this generate uuids locally?

yes. crypto.randomUUID (v4) and an in-browser v7 implementation run in your browser.

what is the 4 or 7 in the uuid?

the version digit. position 14 (0-indexed) is always the version: 4 for v4, 7 for v7.

why does my v7 look almost the same as the last one?

because v7 is time-ordered. two uuids generated in the same millisecond share their first 12 hex chars.

what about ulid or ksuid?

ulid and ksuid are similar time-ordered designs. v7 is now the standard ietf version — prefer it for new work.

## related tools

  • base64 encode and decode base64 strings (client-side, unicode-safe).
  • jwt decoder decode JWT header and payload client-side. no signature verification.

## references

  1. RFC 9562 — uuid formats (replaces rfc 4122)
  2. MDN — Crypto.randomUUID
  3. Buildkite — goodbye integers, hello uuidv7
ad slot · tool-uuid