Two Answers to the Same Question
"How do I generate a unique ID without a central counter?" has two popular answers in 2026: UUID v4 and ULID. Both give you a practically-guaranteed-unique identifier without coordinating with a database, but they make very different tradeoffs.
UUID v4: Pure Randomness
A UUID v4 is 128 bits, almost entirely random — 122 bits of randomness plus a 4-bit version marker and a 2-bit variant marker fixed by the spec. Generated correctly (using a cryptographically secure random source, not Math.random), collisions are so astronomically unlikely they're not a practical concern. The tradeoff: two UUIDs generated a millisecond apart, or a year apart, look completely unrelated. Sorting a table by UUID tells you nothing about insertion order, and as a database primary key, UUID v4's randomness causes index fragmentation — every insert lands in a random position in a B-tree index instead of appending to the end.
ULID: Sortable by Design
A ULID is also 128 bits, but split differently: 48 bits encode a millisecond-precision timestamp, and the remaining 80 bits are random. Encoded in Crockford's Base32 (case-insensitive, no ambiguous characters like I/L/O/U), it becomes a 26-character string that sorts lexicographically in the same order the IDs were created — which means it also sorts correctly as a database primary key, avoiding the index fragmentation problem UUID v4 has. The timestamp is also recoverable: decode the first 10 characters and you get the exact creation time back.
The Monotonic Detail Most Implementations Get Wrong
Two ULIDs generated in the exact same millisecond have identical timestamp segments — their sort order then depends entirely on the random segment, which is, well, random. Some ULIDs generated "in order" within the same millisecond can sort out of order purely by chance. The fix, used by monotonic ULID implementations, is to detect same-millisecond generation and increment the previous random segment by one instead of re-randomizing it — guaranteeing strictly increasing order even at high throughput within a single millisecond.
Picking One
If you need an ID and don't care about sort order or don't want any embedded metadata (a UUID reveals roughly when it was made if it's a ULID, which is sometimes undesirable), UUID v4 is simpler and more universally supported. If the ID is going to be a database primary key, appear in a URL where creation order matters, or you want to eyeball approximate creation time from the ID itself, ULID is usually the better fit.
Generating and Verifying Both
The UUID & ULID Generator/Validator produces both formats correctly — real crypto-random UUID v4 with the right version/variant bits, and spec-correct monotonic ULIDs — and includes a decoder that extracts a ULID's embedded timestamp so you can verify it yourself.
- Generate a UUID or ULID with one click.
- Generate a batch of 5 ULIDs to see monotonic ordering in the same millisecond.
- Paste any UUID or ULID back in to validate its format and decode its contents.
Everything runs locally using your browser's built-in crypto module — nothing is generated on a server.
Frequently Asked Questions
Yes — they're generated using the browser's crypto.getRandomValues (a cryptographically secure random source), not Math.random, with the version nibble and variant bits set correctly per RFC 4122 for a valid UUID v4.
A UUID v4 is pure randomness with no embedded meaning. A ULID encodes a real 48-bit millisecond timestamp plus 80 bits of randomness, so ULIDs sort chronologically and their creation time can be decoded back out — useful as sortable database primary keys.
Yes — the UUID & ULID Generator/Validator does both generation and decoding for either format, entirely offline in your browser. It's a one-time $5.99 purchase — no subscription, no account required.
It uses the monotonic ULID technique: when a new ULID is generated in the same millisecond as the last one, it increments the previous random segment by one instead of generating a fresh random value, guaranteeing strictly increasing lexicographic order.
Yes — the tool includes a built-in round-trip self-test on load: it generates a ULID, decodes the timestamp back out, and displays the delta between the original and decoded time so you can confirm it's exact.