UUID Generator

Worked example: reading the timestamp out of a v7

A v7 UUID is not opaque. Its first 48 bits are the Unix timestamp in milliseconds, big-endian, which means you can recover the moment it was created from the string alone — no database lookup. Take the first three hyphen-separated groups, drop the hyphens, and read the first twelve hex digits as one integer:

0199c82c-c000-7eec-99b0-6ec20fbb1f29
└──────┘ └──┘ │
   8 hex  4 hex │
└───────────┘  └─ version nibble: 7
  0199c82cc000  = 1760000000000 ms
                = 2025-10-09T08:53:20Z

Two lines in any language that can parse hex:

// JavaScript
const ms = parseInt(id.replace(/-/g, '').slice(0, 12), 16);
new Date(ms).toISOString();        // 2025-10-09T08:53:20.000Z

# Python
ms = int(uuid.UUID(id).hex[:12], 16)
datetime.datetime.fromtimestamp(ms / 1000, datetime.timezone.utc)

That is also why v7 sorts usefully: because the time leads the string, lexicographic order and creation order are the same. A v4 has no such structure, so sorting a column of v4s tells you nothing about when the rows were made — see UUID v4 vs UUID v7 for what that does to a B-tree index.

Edge cases & gotchas

• v7 publishes its creation time. The decode above works for anyone who receives the ID. If a UUID is visible to users and the creation time is sensitive — when an account was made, when a draft was started — that is a leak, and v4 is the safer pick. Sortable and private are not the same requirement.
• v5 is deterministic, not unique. The same namespace and name always produce the same UUID: uuid5(NAMESPACE_URL, 'https://example.com/a') is 6639460f-3425-5329-8097-a58f06127860 every time, on every machine. That is the point of it — but it means a v5 is the wrong choice anywhere you are relying on the ID being new, and two callers who happen to hash the same input get a primary-key collision rather than two rows.
• v1 encodes a MAC address and a timestamp. It is the one version that can identify the machine that generated it, which is why it is a poor choice for anything user-facing.
• The nil UUID is a real value. 00000000-0000-0000-0000-000000000000 parses as a valid UUID in most libraries and database types, so it passes a format check while meaning "unset". If a nil UUID would be a bug in your data, check for it explicitly — validation will not.
• Case is not significant, but string comparison is. The format is defined over hex digits, so 550E8400-… and 550e8400-… are the same identifier. They are not the same string, so a UUID stored as text can hold both forms and compare unequal. Storing it in a real UUID column, or normalising to lowercase on the way in, avoids that whole class of bug.
• "Collisions are impossible" is shorthand. v4 has 122 random bits, so a collision is not impossible, just overwhelmingly unlikely — and only if the bits are from a cryptographically secure source. A weak or seeded random generator is the realistic failure mode, not the birthday bound. On this page the bits that carry uniqueness come from the browser's CSPRNG — crypto.randomUUID() for v4, crypto.getRandomValues() for v7's random field.

The v7 decode, the v7 sort order and the v5 value above were produced by running them (Python 3.14.6, uuid module, RFC 9562 layout). The UUID generated by this page never leaves your browser.