Generate UUID v4, UUID v7, ULID, NanoID, or CUID in bulk, with the entropy and the realistic collision threshold reported for each. The time-sortable formats are the interesting ones: v7 and ULID keep the uniqueness of a random id while sorting in creation order, which is what database indexes want.
Step by step
01Pick the format
UUID v4 for pure randomness, v7 or ULID when the ids will be a database key, NanoID when the id goes in a URL, CUID where its ecosystem is already in use.
02Read the entropy figure
Each format reports its random bits and the rough number of ids you would have to generate before a collision becomes likely. That is the number that decides whether a shorter id is safe for your volume.
03Generate as many as you need
Bulk generation for seeding a database, filling a fixture, or populating a test. Everything comes from the browser's cryptographic random source.
04Take them in a usable shape
Plain lines to paste, JSON as an array, or NDJSON with one object per line for a bulk import.
Worked example
UUID v4 is random, and random is exactly wrong for a primary key. This is the cost that pushed a whole generation of databases toward time-sortable ids.
Given
The same inserts, two key formats
v4 every id lands in a random leaf
the index is touched all over
pages split constantly, cache hit rate
collapses as the table grows
v7 48-bit millisecond timestamp first,
then randomness
new ids land at the right-hand edge
appends stay hot in cache, and
ORDER BY id is creation order for freev7 trades entropy for locality: a 48-bit timestamp takes the place of some randomness, leaving 74 random bits — still far more than any application will exhaust. In return, inserts append rather than scatter, and the id itself carries a creation time you would otherwise store separately. The trade only goes the wrong way if the timestamp is information you cannot afford to expose.
Before you choose a format
Random keys are hostile to B-tree indexes
Databases store rows ordered by primary key, so a random id means every insert lands in a different page. Page splits multiply, the cache stops helping, and the slowdown grows with the table. This is the single most common reason a v4 primary key becomes a performance problem at scale.
Sortable ids leak a timestamp
Anything with a time prefix tells whoever holds it roughly when the record was created — and two ids reveal the interval between them. That is usually harmless and occasionally not, as when public ids let a competitor measure your sign-up rate.
Sequential ids leak volume
Auto-incrementing integers are compact and sort perfectly, and they also tell every customer how many orders you have taken. Enumerable ids in URLs are a recurring source of both business intelligence leaks and access-control bugs.
Shorter is fine, until the volume changes
A 21-character NanoID carries around 126 bits and is safe at almost any application scale. Shortening it further is a real trade — halve the length and you halve the exponent, not the risk. Check the reported threshold against your actual generation rate before trimming.
Format determines where it can travel
UUIDs contain hyphens and are case-insensitive hex; ULIDs are Crockford base32 and avoid the ambiguous characters; NanoIDs use a URL-safe alphabet by default. If the id goes in a path, a filename, or a QR code, that alphabet matters more than the entropy does.
Generated locally, from crypto random
Every id comes from the browser's cryptographic random source, in your browser. Nothing is requested, so a batch generated here is as unpredictable as one generated on your server — and none of them have been transmitted.
The judgement call
The choice is nearly always about where the id lives, not about how unique it needs to be.
A new database primary key
UUID v7
Time-ordered so inserts append instead of scattering, with 74 random bits — ample for any application.
A key in a system that predates v7
ULID
The same sortable-plus-random idea in Crockford base32, with wide library support and no ambiguous characters.
An id that appears in a URL
NanoID
Shorter, URL-safe by default, and tunable in length. Check the collision threshold at your volume.
A distributed id where time must not leak
UUID v4
122 bits of pure randomness and nothing else. The right choice when the creation time is sensitive.
A public-facing customer or order reference
Never sequential
Auto-increment discloses your volume and invites enumeration. Use a random or sortable id externally.
Deduplicating rows by content
Use a hash
A generated id is unique by construction — it cannot tell you two records are the same. Hash the content instead.
Reference
FAQ
v7 for anything that becomes a database key: it prefixes a millisecond timestamp so ids sort by creation order and inserts append rather than scattering across the index. v4 when the creation time must not be inferable from the id, since it is pure randomness and nothing else.
Very little in substance — both put a 48-bit millisecond timestamp in front of random bits so the id sorts by creation time. UUID v7 is a standard UUID and fits anywhere a UUID column already exists; ULID is 26 Crockford base32 characters, slightly shorter and free of ambiguous letters.
Random ones are. A B-tree index keeps rows ordered by key, so v4 ids land in random pages, causing page splits and destroying cache locality as the table grows. Time-ordered ids — v7 or ULID — remove that problem entirely while staying unguessable.
For 122 random bits, vanishingly: you would need to generate on the order of a quintillion ids before a collision becomes likely. Each format reports its own threshold here, which matters most for short NanoIDs, where shortening the id lowers the exponent rather than the risk proportionally.
Yes, by design. Anything with a time prefix tells the holder roughly when the record was created, and two ids reveal the gap between them. That is usually fine internally and worth thinking about for ids that appear in public URLs.
They come from the browser's cryptographic random source, generated in your browser with no request made. A batch generated here is as unpredictable as one generated on a server, and none of them have travelled anywhere.
Every id is generated in your browser from its cryptographic random source. No request is made and nothing is transmitted.
Keep going