UUID Generator & Inspector
Generate UUIDs in bulk, or paste one to read its version, variant, and — for v1, v6, and v7 — the timestamp baked into it.
Runs entirely in your browser. Nothing you paste here is uploaded, logged, or sent to analytics.
v4 or v7?
For a new database primary key, use v7. Both are unguessable in practice, but v7 puts a 48-bit millisecond timestamp in its leading bits, which means UUIDs sort in creation order.
That single property is what makes v7 worth switching to. A random v4 key inserted into a B-tree index lands at an arbitrary leaf every time, so the index's hot pages never stay in cache and the tree fragments. A time-ordered key appends to the right-hand edge, which is the access pattern B-trees are built for. On a large, write-heavy table this is the difference between an index that fits in memory and one that does not.
Use v4 when the value is exposed publicly and creation time is itself sensitive — a v7 UUID tells anyone holding it, to the millisecond, when the row was made.
One caveat worth knowing before you rely on the ordering: v7 sorts by time across milliseconds, not within one. Two UUIDs generated in the same millisecond differ only in their 74 random bits, so their relative order is arbitrary — which is why the bulk output above is not internally sorted. RFC 9562 §6.2 describes optional monotonicity counters that fix this, but they are an extension, and most libraries (including this one) implement the basic form. If you need a strict total order within a millisecond, add a sequence column rather than assuming the UUID provides one.
What the versions mean
| Version | Built from | Sortable | Use it when |
|---|---|---|---|
| v1 | Timestamp + MAC address | No | Legacy only — it leaks the generating machine's MAC address. |
| v3 / v5 | MD5 / SHA-1 of a namespace + name | No | You need the same input to always produce the same UUID. Prefer v5. |
| v4 | 122 random bits | No | General-purpose identifiers with no ordering requirement. |
| v6 | Reordered v1 fields | Yes | Migrating an existing v1 deployment to something sortable. |
| v7 | Unix ms timestamp + 74 random bits | Yes | New database keys, event IDs, anything time-ordered. |
| v8 | Whatever you define | Depends | You have a custom layout and want a version nibble that says so. |
Reading a UUID by eye
In the canonical 8-4-4-4-12 form, the first character of the third group is
the version, and the first character of the fourth group encodes the
variant. In 0192f8a1-2b3c-7d4e-8f90-a1b2c3d4e5f6
the 7 means version 7 and the 8 means the RFC 9562 variant (any of
8, 9, a, or b does).
A value where the fourth group starts with c–f is usually a
Microsoft GUID written with a different byte order — worth knowing when a Windows-generated
identifier will not validate against a strict RFC parser.
How random is this?
Generation uses crypto.getRandomValues(), the browser's cryptographically
secure random source — not Math.random(), which is seeded predictably and must
never be used for identifiers. With 122 random bits, you would need to generate about 2.7
quintillion v4 UUIDs before a single collision became likely.