What Is a UUID? (And Why Developers Generate Thousands of Them)
The first time I saw a UUID — 550e8400-e29b-41d4-a716-446655440000 — I assumed it was encrypted gibberish. It's not. It's just a really, really big random number written in a standard format, and it's one of the most useful ideas in software: a way for any computer, anywhere, to invent an identifier that no other computer will ever accidentally duplicate.
If you've ever wondered what those long IDs in URLs and databases are, or you need to generate some for your own project, this guide covers what UUIDs are, which version to use, and the mistakes to avoid.
UUIDs explained in plain English
A UUID (Universally Unique Identifier) is a 128-bit number, usually written as 32 hexadecimal characters in five groups: 8-4-4-4-12. Version 4 — the one you want in almost every case — fills 122 of those bits with cryptographically random data. The number of possible v4 UUIDs is about 5.3 × 10³⁶. You could generate a billion per second for a century and still be unlikely to see a single collision.
The magic property: no coordination needed. Two servers on opposite sides of the planet can each mint UUIDs independently and they'll never clash. That's why UUIDs power database primary keys, API request IDs, session tokens, and distributed systems everywhere.
When to use UUIDs (and when not to)
- Database primary keys when rows are created on multiple servers or offline.
- Public API identifiers — unlike sequential IDs, UUIDs don't leak how many records you have.
- Idempotency keys: attach one to each request so retries don't double-charge.
- Filenames for user uploads, avoiding collisions and enumeration.
Don't use UUIDs as passwords or secrets by themselves — they're unique, not secret, and they often end up in logs and URLs. And if you need human-friendly IDs (order numbers customers read over the phone), use something shorter and readable instead.
v1 vs v4 vs v7: which version?
Version 4 (random) is the safe default and what our UUID Generator produces. Version 1 embeds your MAC address and a timestamp — avoid it unless you need time-ordering, because it leaks machine identity. Version 7 is the new time-ordered standard: sortable like v1 but random like v4, making it great for database indexes. If your database supports v7 natively, prefer it; otherwise v4 is never wrong.
One more thing: always generate UUIDs with a cryptographic random source (like crypto.randomUUID() in the browser), not Math.random(). The whole uniqueness guarantee rests on the quality of the randomness. And since UUIDs usually travel inside API payloads, our JSON Formatter is handy for keeping those payloads readable while you debug — I wrote a plain-English guide to what JSON is if the format itself is new to you.
Practical tips: storing and sharing UUIDs
How you store a UUID matters. As text, a UUID takes 36 characters; stored as raw 16 bytes in a database, it takes less than half that space. For a small project the difference is irrelevant, but at millions of rows the binary form saves real storage and index size. The trade-off is readability: binary UUIDs are harder to debug by eye, so many teams store text in development and switch to binary only when scale demands it.
UUIDs are also not a security feature on their own. Because they are unguessable, people sometimes use them as 'secret' URLs — and then paste them into logs, screenshots, and support tickets, where they stop being secret. Treat a UUID like an ID, not a password: if access should be restricted, check permissions on the server, do not rely on the URL being hard to guess.
Finally, be consistent about case and hyphens. UUIDs are case-insensitive, but mixing '550E8400...' with '550e8400...' and hyphen-less variants across systems creates duplicate-looking records that are actually the same ID. Pick lowercase with hyphens, enforce it everywhere, and generate fresh ones with a proper random source — our UUID Generator produces cryptographically random v4 UUIDs, one or one hundred at a time, entirely in your browser.