What Is a UUID and When to Use It

The anatomy of a UUID

A UUID is 128 bits long, displayed as 32 hex characters separated by hyphens in an 8-4-4-4-12 pattern. The total space is 2^128 — about 3.4 × 10^38 possible values. That number is so large that even generating a billion UUIDs per second for a century would barely dent the chance of a collision. In practice, UUIDs are treated as globally unique.

A few bits inside the UUID are reserved: a version number tells you how the UUID was generated, and a variant field marks the layout standard. The rest is random data or a timestamp, depending on the version.

550e8400-e29b-41d4-a716-446655440000
| 8 chars | 4 | 4 | 4 | 12 chars |
  time-low  time-mid  version  variant  node/random

UUID versions: v1, v4 and v7

Version 4 is the most common. It fills 122 bits with random data, so each v4 UUID is essentially a lottery ticket — simple, safe and unpredictable. Use v4 when you just need a unique ID and do not care about ordering.

Version 1 is based on the current timestamp plus a machine identifier. It is unique and roughly time-ordered, but it leaks the generating machine's MAC address, which is a privacy concern, so v1 is rarely used today. Version 7 is the modern replacement: it starts with a Unix timestamp in milliseconds, so v7 UUIDs sort chronologically while remaining random enough to be unique. v7 is the best choice for database primary keys, because time-ordered keys keep database indexes compact and fast.

• v4 — random. The default choice for most uses.
• v7 — timestamp + random. Best for database keys and anything you sort by time.
• v1 — timestamp + MAC address. Largely replaced by v7.
• v3 / v5 — name-based (MD5 / SHA-1). Same name always gives the same UUID.

When to use a UUID

Use UUIDs whenever identifiers are created in more than one place: multiple servers, offline devices, or user browsers. A central database sequence would force every creator to ask a single server for the next number; a UUID lets each creator mint IDs independently and merge them later without conflicts. That is why distributed systems, event logs and sync engines rely on them.

UUIDs are also good for anything that must be unguessable — a password-reset link, a private file URL, or an API key. Sequential IDs like 1, 2, 3 invite enumeration attacks, where an attacker simply increments the number to reach other people's records. A random UUID cannot be guessed.

When not to use a UUID

UUIDs are not always the answer. They are 36 characters long, which makes URLs ugly and logs hard to read. In a database they take 16 bytes versus 4 or 8 for an integer, and random UUIDs (v4) fragment indexes, which can slow down very large tables. For a small single-server app, an auto-incrementing integer is simpler and faster.

Also avoid UUIDs as the only user-facing identifier. Users cannot remember or dictate them over the phone. A short slug (like "order-8F3K2") is friendlier for anything humans interact with directly — keep the UUID as the internal key and show the slug instead.

UUID vs ULID

ULID (Universally Unique Lexicographically Sortable Identifier) is a newer alternative that packs a timestamp plus randomness into 26 characters using the Crockford Base32 alphabet. ULIDs are shorter than UUIDs, URL-safe, and always sort chronologically. If you want time-ordered, compact, sortable IDs, ULID is an excellent choice. If you need maximum compatibility with existing tools and standards, UUID v4 or v7 is the safer bet.

Generating and using UUIDs in practice

In practice, generating a UUID takes one click: open a UUID generator, pick v4 for a random ID or v7 when you want time ordering, and copy the result. In code, most languages have a built-in way to do the same — Python has uuid.uuid4(), JavaScript has crypto.randomUUID(), and Java has UUID.randomUUID(). Store the value as a 36-character string, or as 16 raw bytes if storage space matters.

A common pattern is to use a UUID as an idempotency key for API requests: the client generates a UUID for each operation and sends it with the request, and the server records it. If the same request arrives twice — because of a retry or a network hiccup — the server sees the duplicate key and returns the original result instead of performing the operation twice. The UUID makes retries safe without any coordination.

Common UUID mistakes

Three mistakes come up often. First, using random v4 UUIDs as a database primary key in a huge table, where the random order fragments the index — use v7 instead. Second, treating a UUID as a secret: it is unguessable, but it is not a password, so never rely on a UUID alone to protect a resource. Third, generating UUIDs from a weak random source, such as Math.random in older JavaScript — always use a cryptographic source, or the IDs may be predictable.