UUID v4 fills 122 of its 128 bits with random data, so two v4 UUIDs have no relationship and collision odds are negligible — but they have no order, which makes them poor database primary keys because inserts land randomly in the index. UUID v7, introduced in RFC 9562, puts a 48-bit Unix millisecond timestamp at the front followed by random bits, so newer IDs are always larger than older ones and sort chronologically. That locality makes v7 the recommended choice for new database keys, at the cost of revealing roughly when each ID was created.

The short decision tree for 2026 is: pick v7 if your stack supports it and you want sortable identifiers — it is ideal for primary keys. Fall back to v4 when you simply need an unpredictable, one-off random identifier and order does not matter. Choose v5 (name-based) when you need a deterministic ID derived from a namespace plus a name, so the same input always maps to the same UUID. v1 still exists for legacy systems; the nil and max UUIDs are special sentinel values.

AnyTool UUID Generator runs entirely in your browser. Random UUIDs use the Web Crypto API — crypto.randomUUID or crypto.getRandomValues — and name-based v5 UUIDs are hashed with crypto.subtle SHA-1, all on your device. Nothing you generate is transmitted, saved or tracked, and the page keeps working offline after the first load. To protect privacy, v1 UUIDs here use a random node rather than your real network MAC address.

UUIDs are not coordinated by a central authority, so uniqueness is probabilistic rather than guaranteed. A v4 UUID has 122 random bits, giving about 5.3 × 10^36 possibilities; you would need to generate billions of UUIDs per second for many years before a single collision became likely, so in practice they are treated as unique. v7 inherits the same large random space while adding a timestamp. Name-based v5 UUIDs are intentionally not unique — the same namespace and name always produce the same UUID, which is exactly their purpose.