A UUID is a 128-bit identifier written as 36 characters in the familiar 8-4-4-4-12 pattern, like f47ac10b-58cc-4372-a567-0e02b2c3d479. The point is to mint an ID on any machine, at any time, without asking a central database whether it's taken — and still be confident it's unique. This tool generates them in bulk, so you can copy a hundred at once or download them as a text file. Everything runs in your browser.
UUID versions explained
- UUID v4 (random) — 122 bits of randomness and the version you'll see most often. Reach for it when you need uniqueness and don't care about ordering.
- UUID v7 (time-ordered) — standardized in RFC 9562. The first 48 bits are a Unix millisecond timestamp and the rest is random, so the IDs naturally sort by creation time.
- Short ID (base62) — not a real UUID, but a compact 22-character random ID using A–Z, a–z, and 0–9. Handy for short URLs and human-friendly references.
- Nil UUID — all zeros (
00000000-0000-0000-0000-000000000000). Used as a placeholder or default "no value" marker.
v4 or v7 for your database?
This is the decision that actually matters. Random v4 keys land in unpredictable spots in a B-tree index, so a write-heavy table in MySQL (InnoDB) or SQL Server spends time reshuffling pages and fragmenting the index. Because v7 IDs increase over time, new rows land next to each other — inserts stay fast and the index stays tidy, all while remaining globally unique.
My default: use v7 for primary keys and v4 for everything else — public-facing IDs, idempotency keys, correlation IDs in logs. If your stack already generates UUIDs a certain way, don't rewrite it for this alone; the gap only shows up at real scale.
How unique are UUIDs, really?
UUID v4 has 2^122 possible values. To hit even a 1% chance of a single collision you'd need to generate about 2.6 × 10^17 of them. For any normal application you can treat them as unique and stop worrying. The one caveat: uniqueness depends on a good random source, which every modern browser and runtime provides through a cryptographic generator.
A v7 UUID leaks a timestamp
Because v7 (and the old v1) embed the creation time, anyone who sees the ID can read roughly when the record was made — and sometimes guess neighboring IDs. That's fine for internal keys, but if you expose IDs publicly and the timing is sensitive, use v4 instead, or don't treat any UUID as a secret.
FAQ
What is the difference between a UUID and a GUID?
+
Nothing meaningful. GUID is Microsoft's name for the same 128-bit value everyone else calls a UUID. Same format, same guarantees — you can use the terms interchangeably.
Are UUIDs guaranteed to be unique?
+
Not guaranteed, but the collision odds are negligible. With 122 random bits in a v4 UUID, you'd have to generate roughly a billion per second for 85 years to reach a coin-flip chance of one duplicate.
Should I use a UUID as a database primary key?
+
Yes, if you pick the right version. Random v4 keys fragment the index on write-heavy tables; time-ordered v7 keeps new rows adjacent and restores most of the performance while staying globally unique.
Can I use a UUID as a secure token?
+
A v4 UUID from a cryptographic source is hard to guess, but v1 and v7 embed a timestamp and are partly predictable. For password resets or session tokens, generate a dedicated random secret rather than leaning on a UUID.
Why is a UUID 36 characters long?
+
It's 128 bits written as 32 hexadecimal characters, plus the four hyphens that split it into the 8-4-4-4-12 pattern — 36 characters in total.