UUID and ULID generator
Generate cryptographically random UUID v4 values and lexicographically sortable ULIDs in bulk.
What this does
This generates identifiers in bulk using the browser's cryptographically
secure random number generator. UUID v4 is the familiar
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx form defined by RFC 4122,
with 122 bits of randomness. ULID is a 26-character
Crockford-Base32 string: a 48-bit millisecond timestamp followed by 80
random bits, designed so that sorting the strings sorts by time.
Generation is entirely local — crypto.randomUUID() and
crypto.getRandomValues() — so nothing is fetched and no two
users can receive the same value from a shared server.
When you'd use it
- Seeding test data or fixtures that need realistic-looking IDs.
- Creating a correlation ID for a log trace or a request you're debugging.
- Generating primary keys for a migration or a one-off script.
- Producing an idempotency key for an API call.
- Filling in a config value that expects a UUID (a client ID, a namespace).
Worked example
Generate 3 UUID v4 values:
b1e7c0a2-4f3d-4a6b-9c21-7d8e5f0a1b2c 0f9a8b7c-1d2e-4f30-8a1b-2c3d4e5f6071 7c6b5a49-3827-4160-95a4-b3c2d1e0f9a8
Tick "Remove dashes" and "Uppercase" and the first becomes
B1E7C0A24F3D4A6B9C217D8E5F0A1B2C — the compact form some
systems store. Switch to ULID and generate 3:
01J9Z8QK3M4N5P6Q7R8S9T0V1W 01J9Z8QK3M7X8Y9Z0A1B2C3D4E 01J9Z8QK3MF5G6H7J8K9M0N1P2
All three share the same leading characters because they were created in the same millisecond; the tails differ. Sort them as plain strings and they stay in a sensible order — that's the property a random UUID doesn't give you.
Limits and gotchas
- ULIDs reveal creation time. Don't use them where that timing is sensitive.
- No monotonic ULID mode. ULIDs generated within the same millisecond are not guaranteed to sort in creation order relative to each other.
- UUID formatting is presentation only. Removing dashes or uppercasing doesn't change the underlying value, but some parsers are strict about the canonical lowercase, dashed form.
- Not sequential integers. If a system expects an auto-incrementing numeric ID, a UUID or ULID won't fit.
- Case sensitivity. UUIDs are conventionally lowercase; ULIDs are uppercase Base32 and exclude the letters I, L, O, and U to avoid ambiguity.
Frequently asked questions
- Are these safe to use as unguessable tokens?
- UUID v4 has 122 random bits from the browser's cryptographic RNG (
crypto.randomUUID), so it is effectively unguessable and fine as an opaque identifier. It is not a substitute for a real secret with rotation and revocation, but as a hard-to-enumerate key it is solid. ULID's random section has 80 bits, which is strong but lower; its timestamp portion is not secret at all. - Why would I choose ULID over UUID?
- A ULID starts with a 48-bit millisecond timestamp, so lexical sort order matches creation order. That makes ULIDs pleasant as primary keys: inserts stay roughly sequential (kinder to B-tree indexes than fully random UUIDs) and you can eyeball which record is newer. The trade-off is that a ULID leaks its creation time.
- Will I ever get a duplicate?
- For UUID v4 the collision probability is negligible for any realistic volume — you would need on the order of a billion billion values before it becomes a practical concern. For ULIDs generated here, two created in the same millisecond are independent random values, so a collision needs an 80-bit clash within that millisecond, which is also negligible. This tool does not implement ULID monotonic mode, so same-millisecond ULIDs are not guaranteed to sort in generation order relative to each other.
- Which UUID version is this, and do you support v1 or v7?
- This generates version 4 (random). v1 embeds a MAC address and timestamp and is rarely wanted today. v7 is the newer time-ordered UUID that serves the same purpose as ULID; it is not generated here yet, but a ULID covers the same need with a shorter, case-insensitive string.