All three produce 128-bit identifiers you can generate without asking a central server. They differ in how the bits are used. Generate and inspect them with the UUID Generator and the UUID & ULID Decoder; the background is in How UUIDs Work.
Example values
- Example UUID v4:
f47ac10b-58cc-4372-a567-0e02b2c3d479 - Example UUID v7:
01a17fce-7800-7abc-8123-456789abcdef(its first 48 bits are the Unix time in milliseconds: 2026-10-28 00:00:00 UTC) - Example ULID:
01M5ZWWY0004HMASW9NF6YY093(the first 10 characters are the same time)
At a glance
| UUID v4 | UUID v7 | ULID | |
|---|---|---|---|
| Bits | 122 random + 6 fixed | 48 time + 74 random-ish + 6 fixed | 48 time + 80 random |
| Text form | 36 characters, hex with hyphens | 36 characters, hex with hyphens | 26 characters, Crockford Base32 |
| Sorted by creation time | No | Yes | Yes (as text, too) |
| Reveals creation time | No | Yes, to the millisecond | Yes, to the millisecond |
| Standard | RFC 9562 | RFC 9562 | Community specification |
| Index locality in a database | Poor (random inserts) | Good | Good |
What it means in practice
- Random v4 keys scatter inserts across a B-tree index, which causes page splits and cache misses on large tables. Time-ordered v7 and ULID append near the end.
- Time-ordered IDs leak when a record was made. Do not use them where that is sensitive, such as password-reset tokens (use v4 or a secure random token for those).
- Within the same millisecond, v7 and ULID need extra care to stay monotonic; libraries add a counter or increment the random part.
- Both formats are case-insensitive in text, but ULID avoids the letters I, L, O and U so that it is easier to read aloud.
Which to choose
- New database primary keys: UUID v7.
- Identifiers that must reveal nothing: UUID v4.
- Short, sortable, URL-friendly IDs where the 26-character form is welcome: ULID.