UUID / GUID Generator

UUIDs at a glance

A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hex digits with dashes: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version (1-7) and N indicates the variant. The probability of generating duplicate UUIDs is functionally zero — you'd need to generate billions per second for years to expect a collision.

The versions you might actually use

Why v7 is becoming preferred

v4 UUIDs are perfectly random, which is bad for databases — inserts go into random pages of the B-tree, fragmenting the index. v7 UUIDs start with a 48-bit Unix millisecond timestamp, so they sort by creation time. New rows insert at the end of the index, like an auto-increment integer, with the global-uniqueness of a UUID. Best of both.

UUIDs, the practical version

A UUID (Universally Unique Identifier) is a 128-bit number designed to be unique across all systems and time without a central authority. Two systems can generate UUIDs independently and the collision probability is effectively zero. This makes them useful for distributed system IDs, session tokens, database primary keys in high-scale systems, and any situation where you need identifiers that don't require coordination to be unique.

The 128 bits are usually displayed as 32 hexadecimal digits arranged in five groups separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position indicates the UUID version. The N position (specifically the two high bits) indicates the variant, which for essentially all modern uses is variant 10 in binary, meaning the RFC 4122 layout.

The version zoo, and which ones matter now

Version 4: random

The most commonly used UUID today. Every bit except the version and variant fields is generated from a cryptographically strong random source. Because 122 bits are random, you can generate UUIDs at any rate on any number of systems with a collision probability that stays negligible for practical purposes.

V4 UUIDs are the default choice for most needs: database primary keys, request IDs, session tokens, anything where you need a unique identifier without semantic content. The randomness means the same generator produces uncorrelated sequences, which is exactly what you want for unpredictability.

The one drawback of V4 in databases is index locality. Random UUIDs scatter across the B-tree index rather than clustering at the end like auto-increment integers do, which increases page splits and reduces insert performance in some workloads. This isn't usually a big deal, but at very high insert rates it can matter.

Version 7: time-ordered random

Standardized in RFC 9562 (which superseded RFC 4122 in 2024). V7 UUIDs embed a Unix timestamp in the leading bits, followed by random data. This gives you two useful properties at once: the identifier is unique like a UUID should be, and it's roughly sortable by generation time.

The time-ordered aspect solves the index-locality problem. Because sequential inserts produce sequential-ish UUIDs, they cluster in the B-tree instead of scattering, which recovers most of the insert performance that pure random UUIDs give up. For new systems in 2026, V7 is worth considering as the default over V4 for database keys.

V7 doesn't leak much timing information beyond "this was generated after that." The timestamp resolution is milliseconds, and the trailing random bits mean two UUIDs generated in the same millisecond are still uncorrelated.

Version 1: MAC address + timestamp

The original UUID scheme. Combines the generator's MAC address with a high-resolution timestamp. Guaranteed unique across space and time as long as MAC addresses stay unique.

V1 UUIDs leak two things: the generating machine's MAC address (potentially identifiable, especially inside a company) and the precise generation time. For most modern uses this is exactly the wrong tradeoff — V4 or V7 avoid both leaks and are just as unique in practice.

Version 3 and Version 5: hash-based

UUIDs derived deterministically from a namespace and a name. V3 uses MD5; V5 uses SHA-1. Same input always produces the same UUID. Useful when you need a stable UUID for a resource identifier that isn't itself a UUID — like generating a UUID from a URL for use as a cache key.

Because these are deterministic, they're not random and shouldn't be used where unpredictability matters. But for stable resource identification they're occasionally exactly what you need.

Version 2: DCE Security UUIDs

Almost never used in the wild. Included in the spec for historical reasons. If you don't already know why you'd want a V2, you don't need one.

Nil UUID

All zeros. Used as a sentinel value meaning "no UUID" in APIs that require a UUID field but sometimes need to indicate absence. The all-zero value is technically valid as a UUID and can't collide with any generated UUID.

Where I actually use UUIDs

Distributed system IDs

When multiple servers are generating IDs for records that will end up in the same database, an auto-increment column requires coordination. UUIDs remove the coordination requirement — each server generates its own IDs without checking anything.

Request tracing

Every incoming request gets tagged with a UUID that travels through every downstream service call. When you're debugging why a specific request failed, having a UUID to search all the logs for is enormously more efficient than trying to correlate timestamps and other indirect signals.

Idempotency keys

APIs that mutate state often accept an idempotency key — a UUID chosen by the client. If the same request is sent twice with the same key, the server recognizes the duplicate and returns the cached response instead of performing the action again. This protects against duplicate charges when a payment API times out and the client retries.

Session tokens for anonymous users

Shopping carts, form drafts, quiz-taking sessions — anywhere a user needs continuity without an account. Generate a UUID, store it in a cookie, use it to key server-side state. When the session expires or the user closes the browser, the state is orphaned but that's fine because it wasn't tied to a real account.

Object identifiers in cloud APIs

AWS, Azure, and GCP all use UUIDs (or UUID-like identifiers) heavily. Resource IDs, request IDs, correlation IDs, trace IDs — the terminology varies but the underlying data is usually a UUID or something similar.

Common questions and misconceptions

"UUIDs guarantee uniqueness"

Only probabilistically. V4 UUIDs have 122 bits of randomness, so the birthday problem says you'd need to generate about 2^61 UUIDs to have a 50% chance of a collision. That's more UUIDs than any real system will generate in the lifetime of the universe. So in practice, yes, they're unique. But it's not a mathematical guarantee, it's an overwhelming probabilistic one.

"UUIDs are longer than necessary"

128 bits is more than most single-system needs, but the point isn't just per-system uniqueness — it's global uniqueness across all systems and time. That requires enough bits that the birthday problem doesn't bite you at galactic scale. Smaller identifiers (nanoids, snowflake IDs, ULIDs) work fine for many use cases but have their own tradeoffs.

"UUIDs are slow in databases"

The concern is index performance. V4 UUIDs scatter across the index; V7 UUIDs cluster like sequential IDs. On modern hardware with proper indexing, the difference is smaller than people often assume, but it exists. If you're building a system that inserts millions of rows per second, this matters. If you're building something that inserts a hundred rows per second, it doesn't.

"UUIDs are unguessable"

V4 UUIDs are, essentially. V1 UUIDs are somewhat guessable if you know the generating machine's MAC and roughly when the UUID was created. V7 UUIDs leak generation time but not much else. V3 and V5 are deterministic and completely guessable if you know the namespace and name inputs. So it depends on the version — but if you need unguessability specifically for security purposes, use V4 or use a purpose-built cryptographic identifier.

"UUIDs are unique globally"

They are, for all practical purposes. But two implementations of the same UUID version generated on two different systems are unlikely to collide only if both use good randomness sources. Poor entropy on virtualized systems has occasionally produced non-unique UUIDs in the past. Modern systems fix this, but the potential exists in principle.

Formatting variations

The canonical UUID format uses hyphens, but you'll see variations:

• With hyphens: 550e8400-e29b-41d4-a716-446655440000
• Without hyphens: 550e8400e29b41d4a716446655440000 (used in some APIs)
• Braced: {550e8400-e29b-41d4-a716-446655440000} (common in Microsoft contexts)
• URN format: urn:uuid:550e8400-e29b-41d4-a716-446655440000 (used in RFC 4122 examples)
• Base64-encoded: not standard but occasionally used to save characters in URLs

All of these represent the same 128 bits. Different systems have different preferences and different parsers. When storing UUIDs, decide on a canonical form and normalize on input.

Related tools

If you need to encode binary data (including UUIDs stored as raw bytes) into text form, the Base64 Encode/Decode tool handles both standard and URL-safe encoding.

If you're generating identifiers for use in a signed context — like a JWT — the JWT Decoder can decode existing tokens to see what identifiers they carry.

Privacy

UUID generation happens entirely in your browser using the browser's built-in cryptographic randomness. No UUIDs are sent to any server. Nothing about your session is logged beyond standard analytics. When you close the tab, the generated UUIDs are gone from any record except wherever you copy-pasted them.