UUID Generator

Anatomy of one UUID

Pick one off the page above. It looks like 550e8400-e29b-41d4-a716-446655440000 — 32 hexadecimal characters arranged 8-4-4-4-12, with four hyphens for legibility. The hyphens are cosmetic. The hex itself is 128 bits, the standard size for a UUID per RFC 4122 (now RFC 9562).

Two specific positions are not random. The 13th character is the version nibble — it tells you how the UUID was generated. The 17th character is the variant nibble — it identifies the value as an RFC-4122-style UUID rather than one of the legacy Microsoft/NCS layouts. In any v4 UUID, the 13th character is exactly 4, and the 17th is one of 8, 9, a, or b. That leaves 122 bits free for randomness.

v4 vs v7: which version to actually use in 2026

Until recently, the practical answer was "use v4 for everything." That changed in 2024 when RFC 9562 standardized UUID v7 — a time-ordered UUID built from a 48-bit Unix-millisecond timestamp followed by 74 bits of randomness. v7 is monotonic (newer UUIDs sort later than older ones) while still being collision-resistant for any realistic workload.

The decision:

• Use v7 if the UUID will be a database primary key or anywhere the values need to be ordered by creation time. v7 plays well with B-tree indexes — inserts go to the right edge of the tree instead of fragmenting random pages. This is a 5–10× write throughput improvement on Postgres for high-insert tables vs v4 keys.
• Use v4 if the UUID is a public-facing token (session ID, password-reset token, share link) where you specifically do not want anyone to be able to guess what was generated before or after. v4 reveals nothing about timing.
• Avoid v1. It embeds the MAC address of the generating machine, which is a real-world information leak.
• v3 and v5 are deterministic (hash of a namespace + name). Useful for the narrow case where you need the same input to always produce the same UUID — almost no application code actually needs this.

This tool generates v4. If you need v7 or a different format (hex, base64, raw bytes), the secure random generator handles those cases.

The collision math, with the actual numbers

v4 has 122 random bits, so 2¹²² ≈ 5.3 × 10³⁶ possible values. The relevant question — when do collisions start to matter — is answered by the birthday paradox: after generating roughly √(2¹²²) ≈ 2.3 × 10¹⁸ UUIDs, the probability of any collision crosses 50%.

Translated to operational rates: if you generated one billion v4 UUIDs every second, you would need to keep generating for about 73 years before reaching even-odds of a single duplicate. At one million per second, hundreds of millennia. At a more realistic rate of a thousand per second across all your services, the heat death of the sun arrives first.

The collision risk for v4 is, for practical purposes, zero — but only when generated from a cryptographically-strong RNG. If your platform's UUID library is seeded from a weak source (a non-CSPRNG, or the seed was set by accident), 122 bits of theoretical entropy can collapse to far less. Always confirm the library you are using calls into the OS CSPRNG (/dev/urandom on Unix, BCryptGenRandom on Windows). The standard libraries in Ruby, Python, Go, Java, and Node do.

Common mistakes I see in production code

• Using string instead of a native UUID column type in Postgres. A native uuid column stores the value in 16 bytes; storing it as varchar(36) uses 37 bytes (plus length prefix) and disables UUID-typed query optimizations.
• Using v4 as a primary key on a hot insert path without measuring index fragmentation first. On tables with millions of rows and many inserts per second, v4 keys can degrade insert throughput substantially. Switching to v7 — or to a sequential ID with a UUID as a secondary external identifier — usually fixes it.
• Treating UUID strings as case-sensitive. RFC 4122 §3 says they are case-insensitive; 550E8400-E29B-41D4-A716-446655440000 and the lowercase version are the same value. Always normalize on input.
• Including a UUID in a URL that should not leak ordering. If you generate v1 or v7 UUIDs for resources and put them in URLs, anyone with two URLs can tell which was created first. Use v4 for anything in a public URL where ordering is sensitive.
• Trusting client-generated UUIDs without server-side uniqueness checks. Even with negligible collision probability, malicious clients can intentionally submit duplicates. UUID uniqueness is a defensive assumption, not a security boundary.