Generate random identifiers — UUID v4, time-sortable UUID v7, ULID, or Nano ID — in whatever quantity and format you need, right in your browser.
Files never leave your device
Formatting options apply to UUIDs only, and take effect the next time you generate.
Four formats, one job: hand you an identifier you can be confident nothing else on Earth already
has. Where they differ is what they optimise for beyond that — pure randomness, sortability, or
length — and this page generates all four, in bulk, without a request ever leaving your browser.
UUID v4: 122 bits of randomness, nothing else
A UUID v4 like 0f1a2242-40af-40c7-b17e-386fb1d41e74 is 128 bits with two fixed points: the
character at position 15 is always 4, marking the version, and the character at position 20 is
always 8, 9, a or b, marking the RFC 4122 variant. Every other bit is random, which is the
entire design — no structure to exploit, and no relationship at all between two ids minted a second
apart.
UUID v7 and ULID: identifiers that sort by when they were made
Generate two UUID v7 ids back to back — 019fccdd-3d93-7000-a933-9e25978bfe16 and
019fccdd-3d93-7001-97c9-7817dd6a1084 — and the first 12 hex characters are identical: that's a
48-bit Unix millisecond timestamp shared by both, since they were minted in the same tick. Decode
019fccdd3d93 as hex and you get 1785848479123, which is 2026-08-04T13:01:19.123Z — the actual
moment of generation is sitting inside the id, in plain hex. The 7 right after it is the fixed
version nibble, not part of the payload — the three digits following that, 000 versus 001, are a
12-bit counter that breaks the tie between ids sharing a millisecond, so the pair still sorts in the
order it was minted, and the remaining bytes are 62 random bits.
A ULID reaches the same result differently: 01KZ6DTFCKZHEZM2VSK1ZVTDFA splits into a 10-character
timestamp, 01KZ6DTFCK, and a 16-character random tail, ZHEZM2VSK1ZVTDFA — 80 bits of randomness
this time, Crockford base32 instead of hex. Crockford's alphabet deliberately drops I, L and O
— easy to confuse with 1 and 0 when read aloud or copied onto paper — plus U, dropped instead
to cut the odds of an id spelling an obscenity by accident.
Tip:Using the id as a primary key? A time-ordered format like UUID v7 or a ULID inserts at the end of a B-tree index every time, the same access pattern a plain auto-increment integer gets — a random UUID v4 key inserts in the middle instead, forcing the database to split index pages all over the tree rather than just appending to the last one.
Nano ID: short, random, and URL-safe
CNBRohZ0f_k_I54PwLe9A is a Nano ID at its default length: 21 characters, drawn from a 64-character
alphabet that's safe to drop straight into a URL path with no further escaping. Each character is an
unbiased 1-in-64 pick, so 21 of them work out to 126 bits of randomness — more than UUID v4's 122 —
in a string about 40% shorter than a UUID's 36 characters. It carries no timestamp and has no
relation to sort order at all; it exists purely to be short, unique, and pastable straight into a
link.
Tip:Need Nano ID output somewhere case-sensitive systems mangle, or want it to visually match a UUID's length? The size is adjustable from 4 to 64 characters — shrink it for a short share link, or grow it past 21 when the extra margin against collisions matters more than brevity.
Four formats, side by side
Format
Length
Time-ordered
Randomness
Good default for
UUID v4
36 characters
no
122 bits
General-purpose unique id, maximum recognisability
UUID v7
36 characters
yes, to the millisecond
62 bits + a 12-bit counter
A primary key or index that should insert append-only
ULID
26 characters
yes, to the millisecond
80 bits
Same as UUID v7, shorter and easier to read aloud
Nano ID
21 characters (adjustable)
no
126 bits by default
A short token or URL slug, not a database key
Why insert order changes how an index performs
Most databases keep a primary key's index as a B-tree, physically ordered by key value. Feed it ids
that only ever grow — a plain integer, or a UUID v7 or ULID — and every insert lands at the tail of
that order, the cheapest possible place to add a row. Feed it UUID v4 instead and each insert lands
at a random point in the middle, forcing the database to split and rebalance pages it would otherwise
never have touched. The id still uniquely identifies the row either way; only the index's write cost
changes.
Frequently asked questions
Which identifier should I use by default?
UUID v4 if you have no particular reason to want anything else — it's the most widely recognized format, every language and database has a native type for it, and it needs no explaining to the next person who reads your schema. Reach for UUID v7 or a ULID specifically when the IDs are going to be a primary key or an index, where insert order starts to matter.
Why does UUID v7 sort in time order but UUID v4 doesn't?
UUID v4 is 122 bits of randomness with nothing structured about it, so two v4 ids minted a second apart are no more likely to sort near each other than two picked at random — because they are random. UUID v7 replaces the first 48 of those bits with the current Unix timestamp in milliseconds, so an id minted later always has a numerically larger start, which is exactly what string and numeric sorting compare first.
What is a ULID, and how is it different from UUID v7?
A ULID solves the same problem — sortable-by-creation-time identifiers — with a different shape: 26 Crockford base32 characters instead of a UUID's 32 hex digits plus 4 hyphens, 36 characters total. Of the 26, 10 are a millisecond timestamp and 16 are randomness. The practical differences are cosmetic rather than architectural: a ULID is shorter, and its alphabet skips the letters I, L, O and U — I, L and O because they're easily mistaken for 1 and 0 when read aloud or copied by hand, and U specifically to cut the odds of an id accidentally spelling something obscene.
Is a Nano ID as safe to use as a UUID?
For collision resistance, yes — the default Nano ID here draws 21 characters from a 64-character alphabet, each one an unbiased 1-in-64 pick, which works out to 126 bits of randomness, comfortably more than UUID v4's 122. What it doesn't have is a standard binary layout the way a UUID does, and it carries no time information at all, so pick it when you want a short, URL-safe token rather than a database key.
Can I generate uppercase, hyphen-free, or brace-wrapped ids?
Yes, for UUID v4 and UUID v7 — the three format switches apply uppercase letters, strip the hyphens, or wrap the result in curly braces, matching how some drivers and legacy systems expect a UUID literal to look. They're disabled for ULID and Nano ID, since forcing UUID formatting onto either would corrupt their own alphabets.
Does generating these ids run in my browser, or on a server?
Entirely in your browser. Every id is built from your device's cryptographically secure random number generator in JavaScript, and nothing about the request — the type, the count, or the ids themselves — is sent anywhere. That matters if you're pre-generating keys for a system you haven't deployed yet and would rather not have a third party see them.
How many ids can I generate in one batch?
Up to 1,000 at a time. That ceiling exists because every id in a batch renders into one output box, and a browser tab starts to struggle with that much text well before your device's own memory would — it's a UI limit, not a limit on the underlying generator.