UUIDs Explained: Versions, Randomness, Sorting, and Safe Use

The familiar UUID string has 32 hexadecimal characters separated by hyphens, such as 550e8400-e29b-41d4-a716-446655440000. The hyphens are formatting; the underlying value is 128 bits. Some bits identify the version and variant, while the remaining bits carry random data, time-derived data, or hash-derived data depending on the version. Because the space is enormous, random UUIDs can be generated independently with very low collision probability when the random source is strong.

Version 4 UUIDs are mostly random. They are easy to understand and good for test records, request IDs, temporary objects, and distributed creation where no coordination is available. Their weakness is ordering. A database index that receives v4 values jumps around because new IDs do not increase over time. That can matter for very large write-heavy tables. For ordinary application data, v4 is still common and practical, but it should not be mistaken for a secret token. An identifier can be hard to guess without being an authentication credential.

Versions 3 and 5 generate the same UUID when given the same namespace and name. Version 3 uses MD5, while version 5 uses SHA-1. They are useful when stable mapping matters: a namespace plus a product SKU, domain name, file path, or external key can produce repeatable IDs across imports. The tradeoff is predictability. If someone knows the namespace and name scheme, they can compute the same identifiers. Deterministic UUIDs are therefore good for stable references, not for access control.

Version 7 UUIDs combine timestamp information with random bits so newer IDs usually sort after older ones. This makes them attractive for logs, event tables, and databases where insertion order matters. They also remain globally generatable without asking a database for a sequence. The timestamp portion is useful operationally, but it can reveal when an ID was created. That is not always a problem, but it is a real design detail when IDs are public, embedded in URLs, or exposed in customer-facing records.

Integer sequences are compact and naturally ordered, but they require central coordination and can reveal record counts. UUIDs avoid coordination and are easy to merge across systems, but they are larger and can make indexes less cache-friendly. Time-ordered UUIDs reduce some of the index churn without returning to a central sequence. The right answer depends on the workload. A small product table does not need the same ID strategy as an append-only event store receiving thousands of writes per second.

A UUID is an identifier. It is not automatically a session secret, password reset token, API key, or capability URL. Random v4 UUIDs are hard to guess, but security tokens need requirements beyond format: cryptographic randomness, enough entropy, expiration, revocation, storage rules, logging discipline, and clear authorization checks. If the value grants access, treat it as a credential and generate it with a security-focused token design. If it only names a row, a UUID is usually fine.

Use v4 when you want simple random IDs and do not care about sorting. Use v5 when you need repeatable IDs from a namespace and stable name. Consider v7 when records are created over time and ordering helps storage, logs, or debugging. Avoid v1 in public identifiers when hardware or timestamp privacy is a concern. Keep IDs lowercase and consistently formatted, validate input, and document whether the ID is public, internal, stable, or disposable. That documentation prevents later code from giving an identifier more meaning than it should have.