Every serious application eventually needs a way to uniquely identify things — database rows, API resources, session tokens, distributed events. UUIDs (Universally Unique Identifiers) are the standard solution. A UUID is a 128-bit value represented as 32 hexadecimal digits in a familiar format: 550e8400-e29b-41d4-a716-446655440000. Despite appearing random, not all UUIDs are created equal — the version number embedded in the format determines how and why it was generated, and choosing the wrong version creates security or performance problems you may not discover until production.
What Makes a UUID Universally Unique
A UUID has 2^122 possible values — approximately 5.3 undecillion (a number with 36 zeros). The probability of generating two identical UUIDs by chance is so astronomically small that it is treated as impossible for all practical purposes. This property allows independent systems to generate IDs without coordination — no central server, no database sequence, no lock contention.
The UUID format is defined by RFC 4122. It contains five groups separated by hyphens: 8-4-4-4-12 characters (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). The M digit indicates the version (1, 3, 4, or 5), and the N digit indicates the variant, which is always 8, 9, a, or b in standard UUIDs. These digits are not random — they are fixed markers that identify the UUID type.
UUIDs are database-friendly: they fit in a 16-byte column, sort consistently, and work across any database engine. Their main drawback compared to auto-increment integers is that they are not sequential by default, which can cause index fragmentation in B-tree indexes at high insert rates. Version 7 (a newer addition to the spec) addresses this by using a timestamp prefix to make UUIDs monotonically sortable.
UUID v1: Time-Based and MAC-Based
Version 1 UUIDs are generated from two inputs: the current timestamp (measured in 100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine's network interface. The timestamp provides ordering, and the MAC address provides node uniqueness. Two UUID v1s generated on the same machine within the same timestamp window use a clock sequence counter to avoid collisions.
The ordering property of v1 UUIDs is genuinely useful in time-series databases and event logs. Records naturally sort chronologically when sorted by their UUID, and you can extract the generation timestamp from the UUID itself. This makes v1 practical for audit logs, message queues, and distributed event streams.
The security concern with v1 is significant: the MAC address embedded in every UUID exposes the hardware identity of the generating machine. In a public-facing API, returning v1 UUIDs leaks server network interface information to clients. For any externally visible identifier, v4 or v5 is the safer choice.
UUID v4: Random and the Safe Default
Version 4 UUIDs are generated from 122 bits of cryptographically random data. The other 6 bits are fixed version and variant markers. There is no timestamp, no MAC address, and no derivable pattern. A v4 UUID is as close to pure randomness as the UUID format allows.
v4 is the right default for most web application use cases: primary keys in relational databases, IDs for API resources, tokens for file uploads, identifiers for user-generated content. Because v4 reveals nothing about the time or place of generation, it is safe to expose in URLs, API responses, and client-side code.
The one limitation of v4 is that the same input can never produce the same output — each call produces a different UUID regardless of input. If you need deterministic ID generation (the same input always produces the same ID), v5 is what you need.
UUID v5: Deterministic and Namespace-Based
Version 5 UUIDs are generated by hashing a namespace UUID and a name string together using SHA-1. The output is deterministic: the same namespace and name always produce the same UUID. This is the key property that distinguishes v5 from all other versions.
Practical uses for v5 include content-addressed storage (generate a stable ID for a URL or file path), deduplication systems (two records with the same source identifier get the same UUID), and federation scenarios (two systems generating IDs from the same source data will agree on the same UUID without communicating).
The namespace is itself a UUID that scopes the name space. RFC 4122 defines four standard namespaces: DNS, URL, OID, and X.500. You can also create your own namespace UUID (typically a random v4) to prevent collisions with other systems using the same names. The SHA-1 hash used internally in v5 is not used for security — it is just a deterministic mixing function.
Choosing the right UUID version is a simple decision tree: use v4 for random IDs in most web application contexts, use v5 when you need deterministic IDs derived from a known input, and use v1 only in internal systems where timestamp ordering matters and MAC address exposure is not a concern. A UUID generator lets you produce all three formats immediately so you can test your integration without writing boilerplate generation code.