Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
UUID & ULID Generator
A UUID and ULID generator. Produce cryptographically-random version-4 UUIDs or sortable ULIDs, one at a time or in bulk, with one-click copy. Explains when to reach for a random UUID versus a time-sortable ULID, and shows the structure of each. Uses the browser’s secure crypto — nothing is generated on or sent to a server.
122 random bits — unordered, reveals nothing. The default distributed ID.
eb74fa47-52b1-4288-9182-9820252a07ac⧉d3ee79bb-0c9e-461e-a26c-e595f7eb676c⧉101c193c-2b22-4a59-8add-ef850743d062⧉fdb0c2c0-f3b3-478a-bd2a-78fb9b226b05⧉28447950-a516-417c-9780-ea6fe1af4e33⧉
Sometimes you need an ID that any machine can mint without asking anyone. UUIDs and ULIDs are 128-bit identifiers, random enough that independent generators never realistically collide, so no central sequence or coordinator is needed. A browser, an offline device and three servers can all create rows that will never clash.
What it computes
The generator produces two formats, from 1 to 100 at a time, using the browser’s cryptographically secure random source:
UUID v4 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
32 hex digits in groups of 8-4-4-4-12
4 = version; y is 8, 9, a or b (RFC 4122 variant)
122 random bits
ULID TTTTTTTTTTRRRRRRRRRRRRRRRR
10 characters: 48-bit millisecond Unix timestamp
16 characters: 80 random bits
26 characters of Crockford base32- The Crockford alphabet is
0123456789ABCDEFGHJKMNPQRSTVWXYZ. It leaves out I, L, O and U so IDs are hard to misread. - Each character carries 5 bits. The timestamp is written most significant first, so later times produce lexicographically larger strings.
- Each random ULID character uses 5 random bits, so all 80 bits are random and uniform.
A worked example
Take a ULID created at Unix time 1700000000000 ms (November 14, 2023, 22:13:20 UTC). Dividing by 32 ten times and mapping each remainder to the alphabet gives the timestamp part 01HF7YAT00. One millisecond later it is 01HF7YAT01, which sorts after it. The remaining 16 characters are random, so a full ID looks like 01HF7YAT00 followed by sixteen random characters.
| Property | UUID v4 | ULID |
|---|---|---|
| Length | 36 characters with hyphens | 26 characters |
| Random bits | 122 | 80, plus 48 of time |
| Sorts by creation time | No | Yes, to the millisecond |
| Reveals creation time | No | Yes |
| Case | Lowercase hex | Uppercase base32 |
A v4 UUID such as 123e4567-e89b-42d3-a456-426614174000 shows the fixed markers: the 15th character is 4 for the version and the 20th is a, one of the four variant digits. Everything else is random.
Assumptions and limits
- No monotonic counter. Two ULIDs in the same millisecond are unique but their order is random. Libraries with a monotonic mode increment the random part to guarantee order.
- Not UUIDv7. A ULID has a similar layout but a different encoding and is not a valid UUID string.
- Not secrets. Identifiers are unique, not confidential.
- No namespace or name-based IDs. Versions 3 and 5, derived from a name, and version 1 are not generated.
- The timestamp is your clock. A wrong device clock produces wrong ULID times.
How to use the result
- Public identifiers: use v4 UUIDs when the ID should say nothing about when or in what order things were created.
- Primary keys: prefer a time-ordered ID, a ULID or UUIDv7, to keep inserts local in the index; store UUIDs in a native 16-byte column rather than as text.
- Do not rely on order across machines. Clock skew means ordering is approximate; use a database sequence if you need strict order.
- Pick one format per system. Mixing UUIDs and ULIDs in one column or API makes validation and sorting harder, and converting between them later is tedious.
- Generate at the edge. Client-generated IDs let you create records offline and make retries idempotent.
How it works
- v4 UUIDs from the browser’s crypto: 122 random bits, 8-4-4-4-12 hex.
- ULIDs: 48-bit ms timestamp + 80 random bits, 26 Crockford base32 characters.
- Generates 1 to 100 at a time with one-click copy, one or all.
- Explains UUID (unordered) vs ULID (time-sortable) trade-offs.
Frequently asked questions
What is a version-4 UUID?
A UUID, Universally Unique Identifier, is a 128-bit value written as 32 hexadecimal digits in an 8-4-4-4-12 pattern. Version 4 fills almost every bit with random data: 122 random bits, with 6 fixed to mark the version and variant. Two independently generated v4 UUIDs colliding is astronomically unlikely, so they can be created anywhere with no central coordinator, which makes them the default choice for distributed identifiers. The 13th hex digit is always 4.
What is a ULID and how is it different?
A ULID, Universally Unique Lexicographically Sortable Identifier, is also 128 bits, but split into a 48-bit millisecond timestamp followed by 80 random bits, written as 26 characters of Crockford base32. Because the high bits are time, ULIDs created later sort after earlier ones as ordinary strings. That makes them friendlier as database keys: inserts stay roughly in order instead of scattering across the index the way random UUIDs do.
When should I use a UUID vs a ULID?
Use a random v4 UUID when the ID should reveal nothing and ordering does not matter: public identifiers, external references, or any system that expects a standard UUID column. Prefer a ULID, or a UUIDv7, which has the same time-ordered idea, when the ID is a primary key and insert locality matters. Time-sortable keys reduce index fragmentation and give a free creation ordering. The trade-off is that a ULID reveals when it was created.
Can two UUIDs or ULIDs collide?
In theory yes, in practice almost never. With 122 random bits, you would need to generate about 2.7 quintillion v4 UUIDs, roughly 2.7 × 10¹⁸, before the chance of any collision reaches 50%. A ULID has 80 random bits per millisecond, so a collision needs two IDs generated in the same millisecond with the same random part. This tool does not enforce monotonic ordering, so two ULIDs created in one millisecond are unique but not guaranteed to sort in creation order.
Are these safe to use as secrets or tokens?
No. A UUID or ULID is an identifier, not a credential. It is built to be unique rather than unguessable in a security sense, and a ULID exposes its creation timestamp. For session tokens, API keys or password-reset links, generate a dedicated high-entropy secret, such as 256 random bits from a cryptographically secure generator, and store it as carefully as a password. This tool does use the browser’s secure random source, but the format is the wrong shape for a secret.