Short ID Generator
Free short ID generator — ULID, NanoID, KSUID, CUID2 and Snowflake identifiers, with the trade-offs explained: which sort by time, which leak creation time, and which suit a database key. Runs locally in your browser.
Default epoch is Twitter's: 4 Nov 2010.
Runs entirely in your browser — nothing you enter is uploaded or stored.
Short identifiers, and what they trade away
A UUID is 36 characters and unsortable. Every format here is an attempt to improve on one of those two properties, and each gives something up to do it.
The formats
- ULID — 48-bit millisecond timestamp then 80 random bits, in Crockford Base32. Sorts lexically by time, case-insensitive, 26 characters.
- NanoID — pure randomness over a 64-character URL-safe alphabet, default 21 characters. The shortest thing here that is still safely unique. No ordering.
- KSUID — 32-bit second-resolution timestamp then 128 random bits. Sortable with far more randomness than ULID, at 27 characters.
- CUID2 — hash-based, designed so that separate machines cannot collide without coordination. Deliberately not sortable; the author considers exposing creation time a flaw rather than a feature.
- Snowflake — 41-bit timestamp, 10-bit machine ID, 12-bit sequence, as a 64-bit integer. Fits in a bigint column, but assumes you assign machine IDs and tolerate clock skew between them.
Sortability is not free
Every sortable format above encodes when it was created. That is exactly what makes the index behave, and exactly what leaks if the ID is public — creation times, and the rate at which you issue them. If both matter, use a sortable ID internally and an opaque one externally.
Frequently asked questions
Which short ID should I use?
ULID or UUIDv7 if the ID is a database key, because both sort by creation time and keep index inserts sequential. NanoID if it appears in a URL and you want it short. KSUID if you want sortability plus a wider random component. CUID2 if you need collision resistance without a coordinating server and do not need sorting. Snowflake only if you already run the infrastructure it assumes.
Why does sortability matter?
A random primary key scatters inserts across the whole B-tree index, which fragments pages and slows writes as the table grows. An ID with a timestamp in its high bits appends at the right-hand edge instead. On a large table this is the difference between a healthy index and one you rebuild periodically.
Do these leak the creation time?
ULID, KSUID, Snowflake and UUIDv7 all encode a timestamp, deliberately — that is what makes them sortable. If an ID is exposed publicly and the creation time is sensitive, that is a real leak: sequential IDs also let someone estimate your growth rate. NanoID and CUID2 carry no timestamp.
Where does the timestamp come from?
From this page. The engine is compiled to WebAssembly and deliberately cannot read a clock, so the current time is passed in explicitly. That is why the generated IDs match your machine's clock, and why the module has no ambient access to anything.