UUID vs ULID vs Nanoid: Which Unique ID Should You Use?

Prototyping, testing, and visual checks before writing any server-side code.

The online generator prototypes the format; it does not replace production-scale generation.

A primary key filled with UUID v4 values inserts every new row at a random position in the B-tree index, fragmenting pages and slowing writes on a high-volume table. That is not a UUID problem in general — it is a pure-randomness problem: UUID v7 (RFC 9562) encodes a millisecond timestamp in its leading 48 bits and fills the rest with randomness, and ULID does the same idea in Base32. Both append to the end of the index, like an auto-increment, without exposing a usable counter. The UUID generator switches from v4 to v7 without changing the field shape (36 hyphenated characters); the ULID generator offers the shorter 26-character alternative.

Replacing an auto-increment with a UUID, ULID, or Nanoid stops trivial enumeration (trying ?id=124, then 125…) but checks nobody's authorization: an ID obtained through another channel — a shared link, a log line, a referrer header — is still readable if the API does not verify ownership of the resource. ULID adds a specific problem: its first 10 characters encode the creation timestamp in plain sight. That is harmless for a primary key, but not for a token meant to stay opaque — anyone who roughly knows the creation time narrows the search space before even attacking the random portion.

Nanoid's collision resistance depends entirely on size × alphabet. The tool's default (21 characters over the 64-symbol url alphabet) targets a collision probability comparable to a UUID v4 at a realistic generation rate — but every preset changes that math. Switching to the "numeric" alphabet (10 symbols) or dropping to 6-8 characters for a shorter slug can collapse the ID space by several orders of magnitude, with nothing flagging it except the live entropy counter next to the size field.

The UUID tool's format switch (plain, braces, urn:uuid:) and case toggle change the text representation, not the underlying 128 bits — but a column doing plain string comparison does not know that {550e8400-…} and urn:uuid:550e8400-… name the same UUID without normalization first. Same logic for ULID: Crockford Base32 is defined as case-insensitive on decode, but a string UNIQUE constraint is case-sensitive.

Same goal — uniqueness without a central coordinator — four different shapes.

The real options on each tool, as they exist today.

Three concrete situations where the format choice has a measurable effect.

On the UUID generator, the list updates as soon as you change an option — there is no separate "generate" button. On the ULID generator, the decoded timestamp of each ID appears right under the generated row.

The Nanoid generator shows live entropy in bits the moment you change the size or alphabet, so you never have to calculate it by hand.

Node exposes crypto.randomUUID() natively for a UUID v4, no dependency needed. Node's built-in crypto module does not generate v7 — a small npm package like uuid handles the sortable variant.

Node has no built-in ULID support. The ulid package exposes generation plus decoding of the embedded timestamp.

The nanoid package matches the tool's default url alphabet and default size (21 characters), with customAlphabet for a custom alphabet or size.

No install, nothing uploaded, up to 50 IDs per batch, full format options for all three formats. Trade-off: no high-throughput generation in the browser, no monotonicity guarantee across tabs or processes, and a custom Nanoid alphabet capped at 256 characters. Use the pages to prototype a schema or produce fixtures; keep uuid, ulid, and nanoid server-side for production.