What Is a UUID? A Practical Guide

UUIDs show up everywhere in software — database keys, API responses, log entries, file names — but the format is often copy-pasted from documentation without much thought about what it actually guarantees or when a different approach would serve better.

Generate one in your browser (free, instant)

The UUID Generator on keptlocal produces version 4 (random) UUIDs using your browser's native cryptographic random number generator.

1. Set how many you need — from a single UUID up to 10,000 at once.
2. Pick a format: one per line, comma-separated, or a JSON array.
3. Click Generate, then Copy all.

The core idea

A UUID is a 128-bit identifier designed to be unique without any central coordination. That last part is the whole point: a normal auto-increment ID (1, 2, 3…) requires a single authority — the database — to hand out the next number, which means two systems can't independently generate IDs without risking a collision. A UUID sidesteps that entirely. Generate one on a laptop with no network connection, generate another on a server on the other side of the world, and the odds of them matching are, for practical purposes, zero.

The four versions worth knowing

RFC 4122 (and its 2024 update, RFC 9562) defines several UUID versions. They solve different problems:

• v1 — timestamp + MAC address. Encodes when and (originally) where the UUID was generated. Rarely chosen today; embedding a MAC address is a minor privacy leak, and most systems that want sortability now use v7 instead.
• v4 — random. 122 random bits, no embedded information. This is the default choice for almost everything, and what keptlocal's generator produces.
• v5 — deterministic, name-based (SHA-1). The same namespace + name input always produces the same UUID. Useful for converting an existing stable identifier (a URL, an email address) into UUID form consistently, without needing to store a lookup table.
• v7 — timestamp-ordered. Combines a millisecond timestamp prefix with random bits, so UUIDs generated later sort after ones generated earlier — solving the database index fragmentation problem that pure-random v4 UUIDs cause at high insert volumes, while keeping most of v4's unpredictability.

UUID vs. auto-increment integer: the real tradeoff

This comes up in almost every schema design discussion, so it's worth being concrete about the actual tradeoff rather than treating either option as obviously correct.

Integers win on: storage size (4–8 bytes vs. 16), index performance (sequential inserts keep B-tree indexes compact and cache-friendly), and human readability in logs and URLs.

UUIDs win on: decentralized generation (no round-trip to the database needed before you have an ID — useful for offline-first apps, message queues, and distributed systems), merge safety (combining data from two systems that both used auto-increment integers means ID collisions; UUIDs avoid this by construction), and not leaking business information (a sequential ID exposes your record count and creation order to anyone who can see it).

A common middle ground: use v7 UUIDs, which keep the decentralization and non-collision guarantees of a UUID while restoring most of the index-locality benefit of a sequential integer, since they sort roughly by creation time.

Where UUIDs actually get used

• Database primary keys, especially in microservice architectures where services generate their own records independently
• API correlation/trace IDs, tagging a request as it moves through multiple services for debugging
• File and upload naming, to guarantee two users' identically-named files never collide
• Test fixtures and seed data, generating realistic non-sequential sample IDs

Privacy: what happens to the values you generate

Nothing is sent anywhere — crypto.randomUUID() is a built-in browser function, not a keptlocal service. UUIDs exist only in your browser's memory and clipboard until you use them elsewhere.

Generate UUIDs now with keptlocal's free UUID Generator — one or thousands at once. Also useful: JSON Formatter for shaping the output into a fixture file.