Free UUID Generator (v4, v7, v1, v5)

The short answer: v7 for database primary keys, v4 for everything else. UUID v4 is 122 bits of pure randomness — universally supported, collision-safe at astronomical scale, and easy to generate anywhere. It's the right default for public identifiers, session tokens, request IDs, and event IDs. The downside: because v4s are random, inserting them as a primary key scatters writes across your B-tree index, hurting insert throughput as the table grows. v7 fixes that by prefixing a 48-bit Unix millisecond timestamp — new UUIDs are lexicographically ordered by generation time, so inserts stay near the index hot spot. Postgres, MySQL, and SQLite all handle v7 as a drop-in replacement for v4 with better locality. v1 is the older timestamp variant; it's fine but harder to work with (Gregorian epoch, weird byte ordering) and largely superseded by v7. v5 is the odd one out — it's deterministic: the same namespace and name always produce the same UUID. Reach for it when you need a stable ID derived from external keys (email addresses, URLs, external IDs) without a lookup table.

UUID v7 (RFC 9562, published 2024) has a simple layout: 48 bits of Unix milliseconds, 4 bits of version (0x7), 12 bits of random data (called rand_a), 2 bits of variant, then 62 bits of random data (rand_b). That's 74 bits of entropy per UUID — plenty of collision resistance. The timestamp prefix means every UUID generated after another one sorts after it, which unlocks two big wins: primary-key inserts stay clustered instead of scattering (huge for large tables), and range scans by ID approximate range scans by creation time (useful for pagination and log queries). Within the same millisecond, order is essentially random — this generator adds a small counter into rand_a to keep multiple UUIDs from the same tick monotonic, which matters when you generate a burst in a tight loop. If you're picking a primary-key strategy today with no legacy constraints, v7 is the right call.

UUID v5 hashes a namespace UUID and a name string with SHA-1 and formats the first 16 bytes as a UUID. The RFC defines four standard namespaces: DNS for hostnames, URL for URIs, OID for ISO OIDs, and X.500 for LDAP DNs. You can also use any custom UUID as a namespace — the effect is a fresh, non-colliding ID space you own. The killer property: given the same namespace and name, v5 always produces the same UUID. Use it to derive stable internal IDs from external identifiers (an email address, a Stripe customer ID, a Twitter handle) without a database lookup table. Two systems given the same inputs will independently compute the same UUID, which is useful for merging data or de-duplicating records. v5 uses SHA-1, which is broken for collision-resistance but fine here because we only care about hash uniformity, not adversarial resistance. Don't use v5 for anything security-sensitive; use it for keys.

All random bits in this tool come from crypto.getRandomValues — the browser's cryptographically secure PRNG, seeded from the operating system's entropy pool (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). That's the same entropy source your browser uses for TLS session keys and WebCrypto operations. For v4, that gives 122 bits of entropy per UUID — collision probability is negligible even at planet-scale ID generation (you'd need to generate about 2.7 quintillion UUIDs to have a 50% chance of a single collision). For v7, you get 74 bits per UUID within the same millisecond, which is still ample. This tool never uses Math.random(), which is not cryptographically secure and would make UUIDs predictable — an important distinction if you use random UUIDs as session tokens or unguessable resource IDs.

The RFC defines the canonical string form: 32 lowercase hex digits grouped as 8-4-4-4-12 with hyphens. That's what almost every library and database accepts. Uppercase canonical is a common Windows / .NET style — some SQL Server projects prefer it, though the RFC recommends lowercase. Hex only strips the hyphens, useful for putting a UUID in a URL path segment or an environment variable where hyphens are awkward. Braces — {8-4-4-4-12} — is the format Windows GUIDs typically use in configuration files and PowerShell output. URN — urn:uuid:8-4-4-4-12 — is the fully-qualified form defined by RFC 4122 §3, useful when you need to be unambiguous about the identifier type in a multi-scheme system. All formats decode back to the same 128-bit UUID.