UUID Generator

This tool generates the identifiers developers actually reach for, following RFC 9562. Version 4 is 122 random bits. Version 7 puts a millisecond timestamp first, so the IDs sort in the order they were made: a database index on them stays compact, where random v4 keys scatter inserts across the whole index. A ULID holds the same 128 bits as 26 characters of Crockford base32, with the same time-first ordering. Version 5 is name-based: the same namespace and name always give the same UUID, which suits idempotent imports and IDs derived from URLs. The checker reads any UUID, GUID or ULID and tells you its version, variant and, for v1, v6, v7 and ULID, the moment it was created.

1. Pick a type: v4 (random), v7 (time-ordered), ULID, or v5 (name-based).
2. For v4, v7 and ULID, choose how many (up to 500) and press Generate. For v5, pick a namespace and type names, one per line. The UUIDs follow as you type.
3. Choose lower or upper case, hyphens and braces (UUIDs only; ULIDs have one canonical form).
4. Copy one, copy all, or download them as a text file.
5. Paste an existing ID into “Check a UUID or ULID” to see what it is and when it was made.

• v7 and ULID reveal when they were created, to the millisecond, to anyone who can see them. Use v4 where that timing is sensitive, such as public account IDs.
• Within one millisecond, v7 and ULID batches count upwards from a random start (RFC 9562 §6.2, method 2; the ULID spec’s monotonic mode), so IDs made together are adjacent. That is what keeps them in order.
• v5 uses SHA-1 because the standard says so. It is fine for deriving IDs, but it is not a security feature: anyone who knows the namespace and name can compute the same UUID.
• Versions 1 and 6 are read by the checker but not generated. They were designed around a network card’s address, and v7 replaces them for new work.
• Random bits come from your browser’s cryptographic generator (crypto.getRandomValues), and v5 hashing uses its built-in SHA-1. Nothing is sent anywhere or remembered.

v7, in most cases. Random v4 keys land all over a B-tree index, so every insert touches a different page. v7 keys arrive in order, like an auto-increment, but you can still generate them anywhere without asking the database. Choose v4 when you don’t want an ID to reveal when it was made.

They carry the same idea and almost the same bits. v7 fits a native uuid column in PostgreSQL, MySQL or SQL Server as it is. A ULID is shorter to read and type and has no hyphens. The checker shows any ULID as the UUID with the same 128 bits, which is how it would be stored in a uuid column.

They are the same format. GUID is the name Microsoft uses; UUID is the name used in the standard. Windows tools often show GUIDs in upper case with braces, which the format options here reproduce.

In theory yes, in practice no. With 122 random bits you would need to generate billions of UUIDs every second for decades before a duplicate became likely.

The tests use RFC 9562’s own examples: the v1, v6 and v7 samples in Appendix A all decode to 22 February 2022, 19:22:22 UTC. The v5 example is DNS namespace plus www.example.com, which gives 2ed6657d-e927-568b-95e1-2665a8aea6a2. Type that name into v5 and compare.