free_tool
UUID & ULID Generator
Generate UUID v4, time-ordered UUID v7 and ULID ids in bulk, then copy them one at a time or all at once. The bytes come straight from your browser's crypto, so nothing leaves the page. It runs in your browser.
Output
Generating…
Generated locally with crypto.getRandomValues. Nothing is sent anywhere.
Picking the wrong ID scheme bites you later, at the database. I help teams choose keys that index well and migrate the ones that don't.
Get your data model right: book a callv4 is fully random. v7 packs a 48-bit millisecond timestamp into the front, so ids sort by creation time. ULID does the same in Crockford base32, which is shorter and case-insensitive.
which_one
v4 vs v7 vs ULID: pick for your index
Reach for UUID v4 when you just need a unique value and don't care about ordering: API keys, idempotency tokens, anything that lives outside a hot database index. It's random, so it scatters across a B-tree and hurts insert locality at scale.
Reach for UUID v7 or ULID when these become primary keys. Both lead with a timestamp, so new rows land near each other in the index instead of all over it. That keeps inserts cheap and range scans by creation time fast. v7 stays in the familiar UUID format; ULID is shorter and a bit friendlier in URLs and logs.
faq
Questions & answers
- What is the difference between UUID v4 and v7?
- UUID v4 is fully random, so two IDs generated in sequence have no relationship and sort in random order. UUID v7 puts a millisecond timestamp in the high bits and fills the rest with randomness, so v7 values are time-ordered: they sort roughly by creation time while staying unique and unguessable.
- What is a ULID and when should I use it?
- A ULID is a 26-character, time-ordered identifier encoded in Crockford base32, so it is more compact and URL-friendly than a hyphenated UUID while still sorting by creation time. Reach for it when you want lexicographically sortable IDs that read cleanly in URLs and logs; reach for UUID v7 when you need the standard UUID format and 128-bit layout.
- Are these UUIDs cryptographically random and safe to use as primary keys?
- The random bits come from crypto.getRandomValues, the browser's cryptographically secure source, so collisions are not a practical concern and all three formats are fine as primary keys. Note that being unguessable is not the same as being secret: do not treat an ID as an access token on its own.
- Why are v7 and ULID better for database indexes?
- Because they are time-ordered, new rows land near the end of the index instead of scattering across it like random v4 values do. That keeps a B-tree index from fragmenting and reduces page splits and cache misses on insert-heavy tables, which is the usual reason teams move off random UUIDs for primary keys.
- Can I generate UUIDs in bulk, and is it done locally?
- Yes. You can generate many at once and copy the whole batch, and every value is produced in your browser via crypto.getRandomValues with nothing sent to a server. The IDs never leave your machine until you copy them.
Identifiers fighting your database?
Random primary keys, page splits, and migrations you keep putting off. I'll help you pick keys that index well and move the ones that don't, safely. Book a call, or leave your email.
Prefer proof first? See how this plays out in real case studies →