UUID Generator
Generate UUID v1, v3, v4, v5, v7 and ULID identifiers and decode existing UUIDs.
Related tools
About this tool
UUID Generator produces every identifier kind in one page: UUID v4 from the browser's own crypto.randomUUID (RFC 9562 §5.4), UUID v7 from 48 bits of Unix milliseconds plus a monotonic counter and random bits (§5.7 and §6.2), UUID v1 from 100 ns ticks since 1582 with a random node id rather than a MAC address (§5.1), name-based UUID v3 and v5 over a namespace and a name (§5.3, §5.5), the nil and max constants, and ULID as a 10-character Crockford base32 timestamp followed by 16 random characters. You can take up to 1000 at a time, separated by newline, comma, semicolon, pipe or as an SQL list, and print UUIDs as 8-4-4-4-12, without hyphens, in braces or as urn:uuid:, while ULIDs keep their single canonical uppercase form. Because v3 and v5 are deterministic, those two return one identifier rather than a bulk run. The decoder reads an existing UUID's version and variant and shows the embedded time for the versions that carry one, v1 and v7. It does not generate v2, v6 or v8.
Generation and decoding happen entirely in the browser. UUID v4 comes from crypto.randomUUID, the random bytes of UUID v1 and v7 and the random characters of a ULID come from crypto.getRandomValues, and the time prefix comes from Date.now on your own machine. Name-based v3 and v5 are computed here too, from the page's own MD5 and from crypto.subtle for SHA-1, so the namespace and the name you type stay in the page. Nothing reaches the XGM API, the URL keeps only the tool path - the type, output format and count are page state rather than query parameters - and the identifiers you generate are not stored anywhere after the tab closes.
How to use it
- Open the UUID Generator tool.
- Paste or type the input you want to inspect.
- Read the result, which is computed in your browser; the input is not sent to XGM.
- Copy the output only after checking it looks correct.
- Use related XGM tools if you need a broader diagnostic view.
FAQ
Is UUID v7 really sortable by time?
Across milliseconds, yes: the first 48 bits are the Unix millisecond count in big-endian order, so sorting the bytes or the hex string sorts by creation time, which is what makes v7 friendlier than v4 as a database key. Within one millisecond this tool adds the fixed-length counter of RFC 9562 §6.2, on by default, so ids minted in the same millisecond keep the order they were minted in; turn it off and the bits below the timestamp are random again and same-millisecond ids have no defined order. The counter only orders ids minted in this page - it says nothing about ids minted elsewhere in the same millisecond.
When should I use UUID v5 instead of v4?
When the same input must always map to the same identifier. v5 hashes a namespace UUID together with a name (SHA-1, truncated to 16 bytes, with the version and variant bits overwritten), so the same namespace and name give the same UUID on every machine, for ever, with no coordination and no database lookup. v3 is the same construction over MD5 and exists for compatibility with older systems; prefer v5 for anything new. Neither is a security primitive: the name can be recovered by anyone who can guess it.
How unique is a v4 UUID?
Six of the 128 bits are fixed - four for the version and two for the variant - leaving 122 random bits, which is a space of 2^122 values drawn from the browser's cryptographic random source. At any volume a normal application generates, a collision is not a practical concern. It is randomness, not coordination, so nothing prevents a collision in principle; a unique constraint in the database is still worth having.
Should I use UUID v7 or ULID?
Both start with the same 48-bit millisecond timestamp, so both sort by time. UUID v7 is a real RFC 9562 UUID: it fits a uuid column, a UUID type in your language and any API that already validates the 8-4-4-4-12 shape. A ULID is 26 Crockford base32 characters with 80 random bits, shorter to read and case-insensitive, but it is not a UUID and will not go into a uuid column without conversion.
What is the “variant” the decoder reports?
The variant bits sit at the start of the 17th hex digit and say which layout the rest of the identifier follows. “RFC 9562” is the normal case; “NCS (reserved)”, “Microsoft (reserved)” and “Future (reserved)” mark the legacy and reserved layouts, and a Microsoft GUID written with mixed-endian fields typically shows up there. The all-zero Nil and all-f Max UUIDs are reported by name instead of a version number.
Why is the embedded time empty for my UUID?
Only v1 and v7 carry a timestamp. A v4 is random and v3 and v5 are hashes of a namespace and a name, so there is no time to extract - the decoder says so rather than inventing one. For v1 the value is converted from 100-nanosecond intervals since 1582-10-15, and for either version it reflects the clock of whatever machine generated the identifier, so treat it as a hint and not as evidence.