What Is a UUID and When Should You Use One?
A clear explanation of UUIDs — what they are, how they're generated, the differences between v1, v4, and v7, and when to use them instead of auto-increment IDs.
· 8 min read
A UUID — Universally Unique Identifier — is a 128-bit value designed to be globally unique without a central authority. You see them everywhere modern systems need an ID that can be generated independently on a phone, server, or worker without coordinating with anyone.
What a UUID looks like
The standard text form is 36 characters: 32 hex digits plus four hyphens, e.g. 3f50a52e-7a2c-4b6a-9f3e-9c1d4a2b7e10. Internally it is just 128 bits — 16 bytes — that systems exchange as text for human readability.
Two characters in the string carry meaning: the first hex digit of the third group encodes the version (1, 4, 7, etc.) and the first bits of the fourth group encode the variant.
How a UUID is generated
It depends on the version. v1 mixes the current timestamp with the machine's MAC address. v4 is 122 bits of randomness from a cryptographic RNG. v7 takes a Unix millisecond timestamp and pads the rest with random bits, producing IDs that sort by creation time. In practice, v4 is the default for most application code and v7 is the new favorite for database primary keys.
v1 vs v4 vs v7 — which to pick
v4 (random): use when you just need a unique ID and do not care about ordering. Default for most application objects.
v7 (time-ordered): use as a database primary key. Sequentially-issued IDs cluster together on disk, dramatically improving B-tree insert performance compared to v4. Most modern languages now ship v7 generators.
v1 (MAC + time): mostly legacy. Leaks the generating machine's MAC address — avoid in anything user-facing.
When to use a UUID instead of an integer ID
Use UUIDs when IDs are generated client-side (mobile apps, offline-first tools), when you merge data across regions or microservices, when you do not want to leak record counts in URLs, or when you need to allocate IDs before writing to the database.
Stick with auto-increment integers when storage is tight, you need human-friendly numbers (invoice #1042 reads better than a UUID), and you are confident a single source of truth will issue them.
Generating one in any language
JavaScript: crypto.randomUUID(). Python: uuid.uuid4(). Go: github.com/google/uuid. Java: java.util.UUID.randomUUID(). Rust: uuid::Uuid::new_v4(). C#: Guid.NewGuid(). For v7 on platforms that do not yet ship it, the uuid7 npm package and equivalents in Python/Go are stable choices.
Common gotchas
Do not assume v4 randomness equals security — it is unique, not unguessable, and 122 bits is great for collision resistance but you still need a real session token for auth. Do not store UUIDs as text in databases that natively support a uuid type — use the binary type for half the storage and faster comparisons. Do not use Math.random()-derived UUIDs in browsers; use crypto.randomUUID() so the entropy is cryptographic.
Need a few for testing right now?
Keep a handful of stable UUIDs in a TestAssets list — known-good user IDs, order IDs, idempotency keys — and paste them into Postman, your IDE, or a signup form on any device. Far better than hitting an online generator and copy-pasting a fresh value every time.