What Is a UUID? Complete Developer Guide to Universally Unique Identifiers

A UUID is a 128-bit value that identifies something uniquely across all computers and all time. Developers use them as database primary keys, API resource identifiers, session tokens, and file names. Because a UUID is generated locally without asking permission from any central authority, two independent systems can each create UUIDs and be statistically guaranteed never to produce the same value.

This guide explains what a UUID is, how the different versions work, and which version to choose for your next project. It also covers the tradeoffs between the two versions most developers care about in 2026: v4 and v7.

What Is a UUID?#

A UUID, or Universally Unique Identifier, is a 128-bit number used to uniquely identify information in computer systems. The specification is defined in RFC 9562, published by the Internet Engineering Task Force in May 2024, which updated and consolidated earlier standards.

A UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

That string is 36 characters long, including four hyphens. Underneath, it represents a single 128-bit integer. The reason developers use UUIDs instead of simple sequential numbers is coordination. Auto-incrementing integers require a central authority (the database) to assign the next value. UUIDs skip that entirely. Any system, running anywhere, can generate UUIDs on its own and trust that they will not collide with values produced by any other system.

This property makes UUIDs essential in distributed architectures, microservices, client-side record creation, event sourcing, and any scenario where identifiers must be globally unique without a shared sequence generator.

UUID Format and Structure#

Every UUID follows the same visual format: eight hexadecimal characters, then four, then four, then four, then twelve, separated by hyphens.

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

The M character is the version field (4 bits). It tells you which version of the UUID you are looking at. The N character is the variant field (2 bits). It identifies the UUID layout according to the RFC. In standard UUIDs, the variant bits are always 10, which means the N character is always 8, 9, a, or b.

Here is a concrete breakdown:

Not all versions fill these fields the same way. Version 4, for example, ignores timestamps entirely and fills most of the 128 bits with random data. Understanding which bits carry what information is the key to choosing the right version.

UUID Versions Explained#

The current RFC defines eight UUID versions. Most developers only need to understand three or four of them in practice.

Version 1: Timestamp and MAC Address

UUID v1 encodes a 60-bit timestamp (counting 100-nanosecond intervals since October 15, 1582) combined with the 48-bit MAC address of the machine that generated it. The remaining bits include a clock sequence for uniqueness when the system clock changes.

The problem with v1 is the MAC address. It leaks the identity of the generating machine, which is a privacy concern. For this reason, v1 is rarely used in modern applications.

Version 2: DCE Security

UUID v2 is rarely discussed and almost never used. It was designed for DCE (Distributed Computing Environment) security and reduces the timestamp and clock sequence fields to make room for a local domain identifier. You are unlikely to encounter v2 outside of legacy systems.

Version 3: MD5 Hash of Namespace and Name

UUID v3 generates a deterministic UUID by computing an MD5 hash of a namespace identifier and a name. Given the same namespace and name, you always get the same UUID. This is useful for content addressing or mapping known strings to stable identifiers.

The downside is that MD5 is considered cryptographically broken. While the collision risk in UUID v3 is low in practice, the cryptographic weakness of MD5 means v5 is preferred over v3.

Version 4: Random

UUID v4 is the version most developers use today. It fills 122 of its 128 bits with cryptographically secure random data. The remaining 6 bits encode the version (0100) and variant (10). With 122 bits of randomness, the probability of a collision is approximately 1 in 5.3 × 10^36 per pair of UUIDs.

Version 4 is simple, universally supported, and reveals nothing about when or where it was generated. The tradeoff is that it is completely unordered. A list of v4 UUIDs sorted lexicographically is in no meaningful chronological order.

Version 5: SHA-1 Hash of Namespace and Name

UUID v5 works like v3 but uses SHA-1 instead of MD5. Given the same namespace and name, v5 always produces the same UUID. SHA-1 is a stronger hash than MD5, making v5 the better choice for deterministic UUIDs.

The RFC defines three standard namespaces: DNS, URL, and OID. You can also register custom namespaces for your own applications.

Version 6: Reordered Timestamp

UUID v6 takes the same timestamp components as v1 but rearranges them so the most significant bits come first. This makes v6 sortable in lexicographic order, which is useful for database indexing. However, v6 still has the same privacy concerns as v1 because it can embed machine identifiers. It was designed as a transitional format. Version 7 is the intended successor.

Version 7: Timestamp and Random

UUID v7 is the version that RFC 9562 recommends as the default for new applications. It puts a 48-bit Unix millisecond timestamp in the most significant bits, followed by 74 bits of random data.

| 48-bit timestamp ms | 4-bit version | 74 bits random + 2-bit variant |

Because the timestamp occupies the leading bits, v7 UUIDs sort in roughly chronological order. This makes them ideal for database primary keys: new rows always append to the right edge of a B-tree index instead of scattering randomly across the tree.

Version 7 has 74 bits of random data, which is less than v4's 122 bits but still more than enough for uniqueness in any practical scenario.

Version 8: Custom

UUID v8 is a placeholder for vendor-defined or application-specific UUIDs. The RFC allows implementations to use the available bits however they want, as long as the version and variant fields are correct. This gives vendors flexibility to encode proprietary data within a standard UUID structure.

UUID v4 vs v7: The Decision That Matters in 2026#

If you are starting a new project, the UUID version question usually comes down to v4 versus v7. Here is how they compare.

Use UUID v4 when you need identifiers that reveal nothing about when they were created. Session tokens, API keys, password reset links, correlation IDs, and trace IDs are all good candidates for v4. The complete randomness is a feature, not a limitation, in these contexts.

Use UUID v7 when the identifier will be a primary key on a database table that grows to millions of rows. The time-ordered structure means inserts always land at the end of the B-tree index, matching the performance characteristics of auto-incrementing integers. PostgreSQL 18 ships with a native uuidv7() function for exactly this reason.

The performance difference is not theoretical. On a B-tree-indexed table with millions of rows under write pressure, random UUID v4 primary keys cause page splits, cache misses, and write amplification that degrade insert throughput by 2x to 10x compared to sequential keys. Version 7 eliminates this problem while preserving the distributed generation benefits that make UUIDs attractive in the first place.

The main tradeoff with v7 is that it leaks approximate creation time. Anyone who holds a v7 UUID can decode the Unix timestamp embedded in its leading bits. For internal primary keys this is rarely a problem. For public-facing identifiers where creation time is sensitive (user IDs, order numbers in customer-facing URLs), keep v7 as the internal key and expose a separate random token externally.

When to Use UUIDs (and When Not To)#

UUIDs solve a specific problem: generating unique identifiers without coordination. They shine in distributed systems, multi-service architectures, event logs, and any workflow where identifiers are created by multiple independent processes.

But UUIDs are not always the right tool. If a single database owns your sequence and you do not need to generate identifiers elsewhere, an auto-incrementing integer is smaller (4 or 8 bytes versus 16), faster to index, and simpler to reason about. The only downside is that sequential integers reveal row count and creation order, which may or may not matter for your use case.

Several alternatives are worth knowing about:

• ULID (Universally Unique Lexicographically Sortable Identifier) uses 128 bits like a UUID but encodes them in Crockford base32, producing a 26-character case-insensitive string. ULIDs are URL-safe without percent-encoding and sort correctly, but they are not an IETF standard.
• NanoID produces shorter random strings (21 characters by default) and is popular for public-facing IDs where brevity matters.
• KSUID (K-Sortable Unique Identifier) predates UUID v7 and uses a similar timestamp-first approach with a 32-bit random suffix.
• Snowflake IDs (64-bit, used by Twitter and others) are compact and time-sortable but require a central coordinator to assign worker IDs.

For most new projects in 2026, the decision tree is straightforward: use UUID v7 for database primary keys, UUID v4 for tokens and opaque identifiers, and integers when you do not need global uniqueness.

Generate a UUID Instantly#

If you need a UUID right now for testing, prototyping, or a configuration file, the txtnode UUID Generator creates valid UUIDs instantly in your browser. There is no sign-up, no server round-trip, and no data leaves your machine. You can generate multiple versions, copy a UUID to your clipboard with one click, and paste it directly into your code, database migration, or environment variable.

The tool is useful when you are setting up a local database, writing tests that require unique identifiers, populating seed data, or debugging a system that expects UUID-formatted strings. Because generation happens client-side, it works offline and on any device with a browser.

For programmatic generation in your application code, most standard libraries support UUID creation natively. In JavaScript, the crypto.randomUUID() method is available in all modern browsers and Node.js 19.0.0+. Python 3.9+ includes the uuid module with uuid.uuid4() and (from Python 3.14) uuid.uuid7(). Go developers typically use the google/uuid package. Java, C#, Ruby, and PHP all have built-in or well-established library support.

UUID Collision Probability#

A common concern is whether two UUIDs could ever be the same. The math makes this unlikely at any practical scale.

UUID v4 has 122 random bits. The birthday problem tells us that a 50% chance of collision requires generating approximately 2^61 UUIDs (about 2.3 × 10^18). That is two quintillion identifiers. Even if every person on Earth generated one billion UUIDs per day for a year, the total would still fall short of this threshold.

UUID v7 has 74 random bits (plus a timestamp component), giving it roughly 2^37 before reaching the same 50% collision probability within a single millisecond. In practice, this means you would need to generate trillions of UUIDs within the same millisecond to have a meaningful chance of collision, which no real system requires.

In short, UUID collisions are a theoretical concern, not a practical one. If your system generates fewer than billions of UUIDs per millisecond, you will never see a collision.

FAQ#

What is the difference between a UUID and a GUID?

GUID (Globally Unique Identifier) is Microsoft's term for the same 128-bit format defined by the UUID RFCs. The terms are used interchangeably. Windows APIs call them GUIDs; the rest of the industry calls them UUIDs. The underlying binary structure and uniqueness guarantees are identical.

Should I store a UUID as a string or as binary?

This depends on your database and priorities. Storing as a CHAR(36) or VARCHAR(36) is human-readable and easy to query, but uses 36 bytes. Storing as BINARY(16) or BYTEA uses exactly 16 bytes, cutting storage in half and improving index performance. PostgreSQL, MySQL, and most modern databases have native UUID types that handle the conversion automatically. If your database supports a native UUID type, use it.

How do I generate a UUID in my programming language?

Most languages include UUID generation in their standard library or in a widely adopted package:

• JavaScript: crypto.randomUUID() (built into browsers and Node.js 19+)
• Python: import uuid; uuid.uuid4() (standard library since Python 3.4)
• Go: import "github.com/google/uuid"; uuid.New()
• Java: java.util.UUID.randomUUID()
• C#: Guid.NewGuid()
• Ruby: SecureRandom.uuid
• PHP: ramsey/uuid package or uuid_create() with the uuid extension

For quick one-off generation without writing code, the txtnode UUID Generator works in any browser.

Can I sort UUIDs?

UUID v1, v6, and v7 are sortable because their most significant bits encode time. UUID v4 is completely random and does not sort in any meaningful order. If you need time-sortable UUIDs, use v7.

Are UUIDs secure?

UUIDs are not secrets. They are identifiers, not authentication tokens. UUID v4 has enough randomness that an attacker cannot guess or enumerate values, but it was never designed to be a security credential. For authentication, pair a UUID with a separate secret (such as an API key or signed token) rather than using the UUID alone.

Information last checked on 2026-07-18.