UUID Batch Generator Guide: Good Keys, Bad Tokens
UUIDs solve the problem of many places minting IDs without collision. They do not solve the problem of making a value nobody can guess. Keep those goals apart.
Open the tool：UUID Batch Generator
What batch generation is for
Seeding a test database, tagging logs with trace IDs, assigning keys to drafts created offline, agreeing on idempotency keys across services: in each case nobody wants to ask a database for the next number, but duplicates are unacceptable.
Generating dozens at once and pasting them into SQL or JSON is the whole workflow. Order is unrelated to creation time, which matters when you compare generated output with inserted rows.
- Primary keys for test and seed data
- Trace IDs and request correlation
- Offline drafts and multi-writer idempotency keys
Format, version, and storage
A v4 UUID is 32 hex digits plus four hyphens. The 13th character is always 4, the version, and the 17th is one of 8, 9, a, or b, the variant. Output is lowercase, and the randomness comes from crypto.randomUUID(), falling back to crypto.getRandomValues().
Store it in a native uuid column first, binary(16) second, and char(36) only as a last resort. Normalise case before insert, or a case-sensitive collation treats the same ID as two different rows. And never truncate a generated value to fit.
- 8-4-4-4-12, with 4 in the version position
- Lowercase before it reaches the database
- uuid type first, binary(16) next, char(36) last
Boundary: random, unsorted, not secret
v4 is fully random, so inserts land at random positions in the index. On write-heavy tables that means more page splits, slower inserts, and a larger index than an auto-increment key. If you need uniqueness plus rough ordering, look at UUIDv7 or ULID, which put a timestamp first.
A UUID is not a security token: it does not expire, cannot be revoked, and records no issuer, so a leaked one cannot be invalidated. Invite codes, password-reset links, and API keys need server-issued, single-use, expiring random values.
- Random primary keys slow inserts and grow indexes
- For rough ordering, look at UUIDv7 or ULID
- No expiry, no revocation: never a token
FAQ
Can a batch contain duplicates?
With 122 random bits, treat it as impossible. Real-world duplicates almost always come from truncating a string or building IDs from timestamps and counters, not from random collision.
Can I use UUIDs as passwords or invite codes?
No. They never expire, cannot be revoked, and leave no audit trail, so a leak is permanent. They are also far too long for a human to type. Use server-issued single-use tokens instead.
Why can't I sort by UUID?
v4 bits are entirely random, so lexicographic order has nothing to do with creation time. For time ordering, use UUIDv7 or ULID, or store a separate created-at column and sort on that.
Related tool：UUID Batch Generator