Bulk-generate UUID v4, time-ordered v7, namespace v5/v3 and ULIDs, in the format your system wants. Paste any identifier to decode its version, variant and the timestamp hidden inside it.
A UUID is 128 bits, and every version spends those bits differently. The choice affects database performance, sortability, privacy and whether two systems can generate the same id for the same thing on purpose. The generator above makes all of them; this section is about which to pick.
122 random bits, 6 fixed for version and variant. Collision probability is negligible (you would need about 261 ids for a 50% chance of one duplicate), and the id reveals nothing about when or where it was made. The cost is that consecutive v4s are scattered across the whole key space, which fragments B-tree indexes and makes them a poor primary key at scale.
RFC 9562 (May 2024). The first 48 bits are a Unix millisecond timestamp, the rest random. Ids created later sort later, so inserts append to the end of an index instead of splitting pages randomly, and you get a creation time for free. This is the right default for a new database primary key. It does disclose creation time, which occasionally matters.
Deterministic: hash a namespace UUID plus a name, and the same inputs give the same UUID everywhere, forever. Use it when two systems must agree on an id without talking — the id for "example.com" in the DNS namespace is the same in every language and library. v5 uses SHA-1 and is preferred; v3 uses MD5 and exists for compatibility.
Same 128 bits as a v7 (48-bit millisecond time plus 80 random bits) but written as 26 characters of Crockford base32 — no hyphens, no ambiguous letters, case-insensitive, and lexically sortable as a plain string. Popular where ids appear in URLs or logs. It is not a UUID and will not parse as one, though it can be re-encoded into a v7-shaped UUID as the decoder shows.
Take 018f4a6c-9e3b-7c4d-8a2e-1f3b5c7d9e0f. The character after the second hyphen is the version nibble — 7 here. The first character of the fourth group encodes the variant: 8, 9, a or b means the RFC 4122 / 9562 layout that every modern UUID uses. Anything else is a legacy Microsoft GUID or reserved layout, and the decoder says so. In a v7, the first 12 hex digits are a millisecond timestamp, so 018f4a6c9e3b is 1,715,000,000,000 ms after the epoch — 6 May 2024. The decoder does this conversion and shows the timestamp in UTC alongside the relative time.
A clustered B-tree index keeps rows in key order. Inserting a v4 lands at a random position, so the database must find and split a page somewhere in the middle of the tree, on almost every insert. At a few million rows the index is larger than memory, most of those page touches become disk reads, and write throughput collapses. MySQL's InnoDB and SQL Server's clustered indexes are the classic sufferers; PostgreSQL's heap tables are less affected but its indexes still bloat. A v7 or ULID makes inserts monotonic, so they land on the rightmost page and the tree grows without churn. If you must keep existing v4 keys, the usual repair is to add a separate sequential column for the physical order.
Every random bit here comes from crypto.getRandomValues(), the browser's cryptographically secure generator, and v4s use the native crypto.randomUUID(). That matters more than it sounds: a UUID generated with Math.random() can be predicted after observing a handful of outputs, which turns "unguessable" URLs and tokens into guessable ones. Never generate ids that gate access with a non-cryptographic random source.
| Format | Example | Where it appears |
|---|---|---|
| Canonical (RFC 9562) | 123e4567-e89b-42d3-a456-426614174000 | Everywhere; lowercase is the standard output form |
| Uppercase | 123E4567-E89B-42D3-A456-426614174000 | .NET, older Windows APIs; equal by value to the lowercase form |
| Braced | {123e4567-e89b-42d3-a456-426614174000} | COM / registry GUIDs, some SQL Server output |
| Simple / hex | 123e4567e89b42d3a456426614174000 | Python's uuid.hex, MySQL BINARY(16) hex dumps, some REST APIs |
| URN | urn:uuid:123e4567-… | XML, SAML, RFC 4122 URN namespace |
| ULID | 01ARZ3NDEKTSV4RRFFQ69G5FAV | URL-safe ids, log correlation, event streams |
A v4 UUID has 122 random bits from a cryptographic generator. The chance that any two of a billion such ids collide is about 1 in 2.7 quintillion; you would need to generate roughly 2.7 quintillion ids before a duplicate became likely. Nothing is checked against a central registry, and nothing needs to be — the probability is what guarantees uniqueness. The same reasoning applies to the 74 or 80 random bits in a v7 or ULID generated within the same millisecond.
Nothing in the value. GUID is Microsoft's name for the same 128-bit identifier, and modern GUIDs use the same RFC 4122 layout. Two historical differences remain: Microsoft tools often print them uppercase and in braces, and very old COM GUIDs used a different variant (the "Microsoft" or "NCS" variant bits), which the decoder reports if it sees one. A value produced by .NET's Guid.NewGuid() is a valid v4 UUID.
v7, for any new table. Its leading timestamp makes ids increase over time, so inserts append to the end of a B-tree index instead of splitting pages at random positions, which is the cause of the well-known write slowdown with v4 keys in MySQL and SQL Server. The only reason to prefer v4 is if revealing the row's creation time is a problem for your application, since anyone with the id can read the timestamp.
From a v7 or a ULID, yes: the first 48 bits are a Unix millisecond timestamp and the decoder shows it. From a v1 or v6, also yes, as a count of 100-nanosecond intervals since 15 October 1582, which the decoder converts. From a v4, v3 or v5, no — those contain no time information at all, and there is no way to learn when they were made.
A v5 is SHA-1(namespace UUID bytes + name bytes) with the version and variant bits overwritten, truncated to 128 bits. It is deterministic: the same namespace and name always produce the same UUID, in any language. Use it when independent systems need to agree on the id for the same real-world thing without coordinating — for example, deriving a stable id for "example.com" from the DNS namespace, or for a file path from the URL namespace. v3 is the same construction with MD5 and should only be used to match an existing system that requires it.
No. A ULID is 128 bits like a UUID, but it is written as 26 characters of Crockford base32 with no hyphens, and its bit layout does not set the UUID version and variant fields. A UUID library will reject it. The decoder here shows the ULID's timestamp and random component, and also shows the same 128 bits rewritten in UUID form for systems that need to store it in a UUID column, but that rewritten form will decode as an unknown version unless the version bits are overwritten.