How to use
- Choose a type: UUID v4, ULID or NanoID.
- Set the quantity (up to 1,000).
- Adjust the options: uppercase and hyphens for UUID, size and alphabet for NanoID.
- Copy them all or download a text file.
Use cases
- Generating primary keys for seeds and test fixtures.
- Creating time-sortable IDs (ULID) for insert-heavy tables.
- Producing short, secure IDs for URLs (NanoID).
- Populating staging environments with sample data.
Technical concepts
UUID v4
A UUID (RFC 9562) has 128 bits; in version 4, 122 of them are random. The collision probability is negligible: you would need about 2.7 quintillion UUIDs for a 50% chance of a single duplicate.
ULID
A ULID combines a 48-bit millisecond timestamp with 80 random bits, encoded as 26 Crockford Base32 characters. Because it starts with the time, ULIDs sort lexicographically, which improves B-tree index locality compared with UUID v4. Within the same millisecond, the random part is incremented to keep the order.
NanoID
By default NanoID uses 21 characters from a 64-symbol URL-safe alphabet, offering entropy similar to UUID v4 in a shorter string. With custom alphabets, generation uses bit masking and rejection sampling to avoid statistical bias.
Frequently asked questions
Are the IDs cryptographically secure?
Yes. They all use crypto.getRandomValues or crypto.randomUUID, the browser's cryptographic randomness sources.
Should I use UUID or ULID as a primary key?
ULID (or UUID v7) is better for insert-heavy workloads, because time ordering reduces index fragmentation. UUID v4 is ideal when the ID must not reveal its creation time.
What NanoID size is safe?
With the default alphabet, 21 characters give about 126 bits of entropy. Shorter IDs increase the collision risk quickly.