ULID / NanoID / CUID2 Generator
Bulk-generate ULIDs, NanoIDs, and CUID2 — modern UUID alternatives that are shorter, sortable, or collision-resistant.
About
ULID: 26 chars · 48-bit timestamp + 80-bit random · Crockford Base32 · sortable by time.
How to use
- Pick a scheme (ULID, NanoID, CUID2).
- For NanoID/CUID2, choose ID length; for NanoID, optionally edit alphabet.
- Set count and generate. Copy individual IDs or all at once.
About this tool
ShowHide
Generate ULIDs, Nano IDs or CUID2s in bulk, all drawn from the browser's cryptographic random source. Which one you want depends on what the ID has to do. A ULID is 26 characters of Crockford base32 whose first ten encode the creation time in milliseconds, so a list of them sorts chronologically as plain text — that time ordering is why they make better database keys than a fully random UUID, which scatters inserts across an index. Nano IDs are short and configurable: pick the length and the alphabet, which defaults to lowercase letters and digits so an ID survives a case-insensitive filesystem or a URL that someone will retype. CUID2 favours collision resistance and gives away nothing about when or where it was made.
Frequently asked questions
ULID vs UUIDv4?
Both are 128 bits of randomness, but ULID's first 48 bits encode the timestamp — IDs generated later sort after earlier ones, useful for DB primary keys.
Why NanoID instead of UUID?
Shorter (21 chars vs 36), URL-safe by default, and the alphabet is configurable. Same crypto strength as UUIDv4 at default size.
Is CUID2 secure?
Yes — uses crypto-secure RNG and a configurable length. Designed specifically to be hard to guess (no embedded timestamp or fingerprint to leak).
Are these RFC-compliant?
ULID has a community spec. NanoID and CUID2 are de-facto standards with reference implementations. None are RFC-numbered like UUID.
Why does ULID ordering matter for a database?
A primary key that sorts by creation time keeps new rows landing at the end of the index instead of scattered through it, so pages stay dense and inserts stay cheap. A fully random UUID does the opposite, which is why large tables keyed on UUIDv4 fragment their indexes over time.
Does putting the time in the ID leak anything?
Yes — a ULID publicly announces when the record was created, to the millisecond, and two IDs reveal the interval between them. That is fine for an internal row key and less fine in a public URL, where it can expose signup rates or order volume. CUID2 exists for exactly that reason.
Guides on this topic
Related tools
UUID Generator
Generate random version-4 UUIDs in bulk, with copy.
Developer
ULID Decoder (Timestamp & Randomness)
Decode a ULID into its 48-bit creation timestamp and 80-bit randomness — Crockford Base32, case-insensitive, with ISO UTC and epoch milliseconds.
Developer
Snowflake ID Decoder (Discord, Twitter)
Decode a Discord, Twitter/X or Instagram Snowflake ID into its creation timestamp, worker or datacenter, and sequence — with a custom-epoch mode.
Developer
Git Object ID (hash-object)
Work out the git object id of a blob, tree, commit or tag in both SHA-1 and SHA-256, with the header git hashes and the loose object path.
Developer
PGP Public Key Inspector
Read an armored OpenPGP public key: full fingerprint, key ID, algorithm, size, creation and expiry dates, user IDs and subkeys.
Developer
Hash Generator (SHA)
Generate SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text.
Developer