UUID Generator Online

UUID v4 vs v7: which one to use

The two UUID versions you'll encounter most in modern systems are v4 and v7. They solve different problems, and picking the right one depends on whether ordering matters to you.

UUID v4 is 122 bits of cryptographically random data plus 6 fixed version/variant bits. There is no timestamp, no MAC address, no sequence counter — just randomness. That makes v4 IDs completely opaque: you cannot extract creation time or ordering from them. This is the version defined in RFC 9562 Section 5.4 and the one most libraries default to.

UUID v7, introduced in the same RFC, embeds a 48-bit Unix timestamp in milliseconds in the most significant bits, followed by 74 random bits (after version and variant). Because the timestamp occupies the high bits, v7 UUIDs sort lexicographically in creation order. This property is valuable for database primary keys — B-tree indexes stay sequential, reducing page splits and write amplification.

Rules of thumb:

• Use v4 when you need an opaque, unguessable identifier and ordering does not matter — session tokens, correlation IDs, cache keys, anything that won't be a B-tree primary key.
• Use v7 when the ID will be stored in a database index and you want chronological ordering without a separate created_at column — row IDs in Postgres, Cassandra partition keys, event stream keys.
• Avoid v1 unless you're maintaining legacy systems. It leaks the host's MAC address and its timestamp resolution makes ordering unreliable across machines.

Note that v7 timestamps are only millisecond-precision. Two UUIDs generated in the same millisecond on the same machine will have random tiebreakers, so ordering within that window is non-deterministic. For most applications this is fine.

What makes a UUID unique

A UUID v4 has 122 random bits (the remaining 6 bits are fixed version and variant markers). That gives 2¹²² possible values — roughly 5.3 × 10³⁶. To put that number in perspective: if you generated one billion UUIDs per second, it would take about 170 trillion years to exhaust the space.

The more practical question is collision probability, governed by the birthday problem. The chance of at least one collision among n randomly generated UUIDs is approximately 1 - e^(-n^2 / 2^123). Some concrete numbers:

• 1 billion UUIDs — collision probability is about 10^-19, or one in a quintillion. You are far more likely to be struck by a meteorite.
• 1 trillion UUIDs — still under 10^-13. For context, this is roughly one UUID for every star in the observable universe divided by 200.
• 2.7 × 10¹⁸ UUIDs — the 50% collision threshold. You'd need to generate this many before a coin-flip chance of seeing any duplicate.

The critical assumption is that the random source is actually uniform and unpredictable. This generator uses crypto.getRandomValues(), backed by the operating system's CSPRNG, so that assumption holds. If you use Math.random() instead, all bets are off — its internal state is small enough that collisions become plausible at scale.

UUID formats and representations

The canonical UUID format is 32 hexadecimal digits arranged as xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version nibble (4 or 7) and the top two bits of N are the variant (10 in binary for RFC 9562). The 8-4-4-4-12 grouping is just a display convention — the dashes carry no information.

You'll encounter several alternative representations depending on the system:

• With braces — {550e8400-e29b-41d4-a716-446655440000}. Used by Microsoft's COM/OLE infrastructure and Windows registry entries.
• No dashes — 550e8400e29b41d4a716446655440000. Common in URLs and file names where hyphens are inconvenient. 32 hex characters, easy to validate with a regex.
• Base64-encoded — 22 characters (with padding stripped). Useful when you want a shorter string representation, for instance as a URL-safe identifier. Trades readability for compactness.
• 128-bit integer — in languages like Python or Go you can store a UUID as a native 128-bit or big-integer value. Databases like PostgreSQL have a dedicated uuid column type stored as 16 raw bytes.
• URN format — urn:uuid:550e8400-e29b-41d4-a716-446655440000. Defined in RFC 9562 for use in XML namespaces and SOAP messages.

Regardless of representation, all UUIDs are case-insensitive. A716 and a716 refer to the same value. The RFC recommends lowercase output but requires parsers to accept either.

Common UUID use cases

UUIDs solve a specific problem: generating globally unique identifiers without a central authority. Here are the most common places they show up:

• Database primary keys. Using UUIDs instead of auto-incrementing integers lets you generate IDs on the application server before hitting the database. This eliminates round-trip latency, simplifies bulk inserts, and makes database sharding straightforward since there's no central sequence to coordinate. Use v7 if your database uses B-tree indexes — the time-ordered prefix keeps inserts sequential.
• Distributed systems. When multiple services or nodes need to create records independently, UUIDs guarantee uniqueness without consensus protocols. Microservices, event sourcing, and CQRS architectures rely heavily on this property.
• Session and token identifiers. v4 UUIDs make good session IDs because they're generated from a CSPRNG and contain no predictable structure. An attacker cannot guess the next session ID by observing previous ones.
• API idempotency keys. When a client retries a request (e.g., a payment), it attaches a UUID as an idempotency key. The server uses this to detect duplicate requests and return the original response instead of processing the operation twice.
• File and resource naming. Upload handlers, CDN asset paths, and temporary file names commonly use UUIDs to avoid collisions without locking or coordination.

One place UUIDs are a poor fit: user-facing identifiers. A 36-character hex string is hard to read aloud, impossible to remember, and ugly in a URL. For those cases, use a short ID scheme (e.g., base62-encoded) or a human-readable slug instead.

Related generator tools

If you're working with identifiers, tokens, or hashing, these other tools on CodeBoxTools may be useful:

• Password Generator — generate cryptographically random passwords and passphrases of any length, using the same crypto.getRandomValues() API that powers this UUID generator.
• Hash Generator — compute SHA-256, SHA-512, MD5, and other hash digests. Useful when you need a deterministic fingerprint of data rather than a random identifier.
• Bcrypt Generator — hash passwords with bcrypt for secure storage. Different purpose than UUIDs, but often used in the same authentication workflows.