UUID / ULID / NanoID Generator
Generate UUIDv4, sortable UUIDv7, ULIDs and NanoIDs with format anatomy explained.
Format anatomy
First 48 bits = Unix ms timestamp → time-sortable; rest random (RFC 9562).
colored prefix = timestamp · rest = random. Regenerate and watch the prefix tick.
≈ 74 random bits per ID. WebCrypto-secure, generated locally — never logged anywhere.
0 × UUIDv7
How it works
Four ID formats dominate modern systems, and the differences are practical rather than cosmetic. UUIDv4 is 122 random bits formatted into the familiar 8-4-4-4-12 hex layout — maximum unpredictability, zero ordering. UUIDv7 keeps the same wire format but leads with a 48-bit Unix-millisecond timestamp, making IDs roughly time-ordered. ULID packs the same timestamp-plus-randomness idea into 26 characters of Crockford base32, which sorts correctly as a plain string. NanoID is the compact URL-safe option: a configurable-length string over a 64-character alphabet, ideal for short links and public-facing handles.
Everything here is generated locally with the Web Crypto API. crypto.randomUUID() produces the v4s; the v7s are assembled to the RFC 9562 layout — timestamp in the first 48 bits, version nibble set to 7, variant bits set, the rest filled from crypto.getRandomValues. ULIDs use the same construction with the Crockford base32 alphabet, and NanoIDs sample uniformly from their alphabet using rejection sampling so no character is statistically favored. No Math.random anywhere, and no network calls — the IDs exist only in your tab until you copy them.
The anatomy display is the teaching aid: for v7 and ULID the timestamp characters are highlighted separately from the random tail, so you can watch the prefix tick upward as you regenerate and see exactly why these formats sort by creation time. That property is the whole argument for using them as database primary keys — inserts cluster at one edge of the index instead of splattering across it, which keeps B-trees tight under write-heavy load.
Collision math, briefly: with 122 random bits (v4), generating a billion IDs per second for 85 years yields about a 50% chance of a single collision. ULIDs and v7s concentrate their 74 to 80 random bits within each millisecond, which is still vastly more than any realistic same-millisecond volume. For NanoIDs the entropy is length × 6 bits at the default alphabet; the count field here lets you generate in bulk and the per-item and bulk copy buttons get them into your fixtures, seeds or tests without retyping.
Frequently asked questions
UUIDv4 vs UUIDv7 — which should I use?
UUIDv4 is 122 bits of pure randomness; UUIDv7 puts a 48-bit Unix millisecond timestamp in front of 74 random bits. For database primary keys, v7 is usually the better default: new rows land near each other in a B-tree index instead of scattering across pages, which keeps inserts fast and indexes compact. Use v4 when IDs must not reveal creation time — v7 leaks the timestamp by design.
Why are ULIDs lexicographically sortable?
A ULID encodes a 48-bit millisecond timestamp followed by 80 random bits, in Crockford base32 — an alphabet chosen so that character order matches numeric order and ambiguous letters (I, L, O, U) are excluded. Because the timestamp occupies the leading characters, plain string sorting puts ULIDs in creation order. Two ULIDs from the same millisecond sort randomly relative to each other, which is fine for almost every use.
How do random IDs affect database indexes?
B-tree indexes perform best when inserts are roughly ordered. Fully random keys like UUIDv4 cause every insert to hit a random leaf page — more page splits, more cache misses, larger write amplification, and a measurably bloated index at scale. Time-prefixed IDs (v7, ULID) cluster writes at the right edge of the tree like an auto-increment does, while keeping global uniqueness and unguessability of the random portion.
How long should a NanoID be?
It depends on volume and your collision tolerance. The default 21 characters over a 64-symbol alphabet carries about 126 bits of entropy — comparable to UUIDv4 — which is overkill for most apps. At 1,000 IDs per hour, a 14-character NanoID needs centuries for a meaningful collision probability. The birthday bound is the math to know: collision risk grows with the square of the ID count, halving entropy bits.
Are these IDs generated securely?
Yes. Every format here draws randomness from the Web Crypto API (crypto.randomUUID and crypto.getRandomValues), which is a cryptographically secure generator — never Math.random. Generation happens entirely in your browser tab with no network calls, so the IDs you generate are not logged or known anywhere else. They are safe to use directly in production systems.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG