UUID Generator

Generate unique UUIDs (v1, v3, v4, v5, v6, v7) for your projects.

Generate one or many UUIDs in any standard version. v4 is the safe default for IDs you don't want to leak metadata; v7 is the modern choice when you want IDs to sort roughly by creation time (much friendlier to database indexes than v4).

Common use cases: database primary keys, request/correlation IDs, idempotency keys for retries, deterministic IDs from a name + namespace (v5), and unique filenames in object storage.

Generated UUIDs

Frequently asked questions

Which UUID version should I use?
For most general-purpose IDs (database keys, request IDs, file names), v4 is the right default — fully random, no leaks about when or where it was generated. For IDs that should sort by creation time (especially as primary keys), v7 is the modern choice: random-looking but time-ordered. Use v1 only if you need legacy compatibility, and v3/v5 when you need deterministic IDs derived from a name and namespace.
Are these UUIDs cryptographically random?
Yes for v4 and v7 — they're seeded by crypto.getRandomValues, the browser's CSPRNG. Collisions are astronomically unlikely (you'd generate a billion v4 UUIDs per second for ~85 years to hit a 50% chance of one collision).
Why are v7 UUIDs better as database primary keys?
v4 UUIDs are random, which makes them awful for B-tree indexes — every insert hits a different leaf page. v7 prefixes each ID with a millisecond timestamp, so inserts append to the end of the index instead of scattering. You keep the global uniqueness while getting back the insert performance of an auto-incrementing integer.
Can I generate many at once?
Yes — use the count input to generate a batch. There's no upper limit beyond what your browser will paste comfortably.
Is a UUID the same as a GUID?
Functionally yes — GUID is Microsoft's name for the same 128-bit identifier format defined by RFC 9562. Same bytes, same uniqueness guarantees.