What Are These ID Formats?

• UUID v4 — A 128-bit identifier generated from random bytes. The most widely used UUID version. Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx (the 4 at position 15 indicates version 4).
• UUID v7 — A 128-bit identifier that embeds a Unix timestamp in the first 48 bits, followed by random bytes. Format: xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx (the 7 at position 15 indicates version 7). IDs are naturally sortable by creation time.
• ULID — A 128-bit identifier encoded as 26 Crockford Base32 characters. The first 10 characters encode a millisecond timestamp, the last 16 are random. Sortable and case-insensitive.

UUID v4 vs v7 — How to Tell Them Apart

Look at the first character of the third group (position 15 in the string, including hyphens). For v4, it's always 4. For v7, it's always 7.

• 550e8400-e29b-41d4-a716-446655440000 — UUID v4
• 019c584d-b523-754b-b5d2-d503d80c1ad5 — UUID v7

The key difference: v7 UUIDs generated later will sort after earlier ones because the timestamp comes first. v4 UUIDs have no ordering guarantee.

When to Use Which

• UUID v4 — Use when you need a random identifier with no ordering requirement. Great for general-purpose IDs, session tokens, or any case where sortability doesn't matter. Maximum compatibility with existing systems.
• UUID v7 — Use when you need time-ordered records in a standard UUID format. Ideal for database primary keys (better index locality than v4), event logs, or any system that benefits from chronological ordering while staying UUID-compatible.
• ULID — Use when you want a compact, sortable, human-friendly ID. The Crockford Base32 encoding is shorter than UUID strings (26 vs 36 characters), avoids ambiguous characters, and is case-insensitive. Good for URLs, user-facing IDs, and systems where string length matters.

Comparison Table