UUID Generator

Which UUID version to pick: v4 is random, but it can slow your database

What a UUID looks like

The canonical form is 32 hexadecimal characters, grouped as 8-4-4-4-12 into five parts, 36 characters total with the 4 hyphens: 550e8400-e29b-41d4-a716-446655440000.

The 13th hexadecimal digit is the version, and the 17th is the variant (the RFC 4122 variant is fixed to one of 8, 9, a or b). So just by reading the 13th digit you know which version a UUID is.

What each version means

The remaining versions each earn their place. v1 embeds a timestamp and the node MAC, which makes values sortable by time but also leaks the machine's MAC address — a privacy cost worth avoiding in any public identifier. v3 and v5 turn a name and a namespace into a stable id, so the same input always yields the same output; that is handy when you want an idempotent, content-derived id such as a UUID for a known URL, with v5 (SHA-1 based) preferred over v3 (MD5 based) for the stronger hash.

How low is the v4 collision probability, really

v4 carries 122 bits of randomness, about 5.3×10³⁶ possible values. By the birthday paradox you would need to generate roughly 2.7×10¹⁸ UUIDs to reach a 50% chance of one collision. At one billion per second that is about 86 years. So in practice you can treat it as collision-free — but "collision-free" is not the same as "safe to use as a security token". The randomness of v4 comes from the implementation's random source, and the spec does not require a cryptographically secure generator. To make an unguessable token, use a dedicated random API, not a UUID.

In day-to-day terms, a v4 UUID is a perfectly good primary key and a perfectly good correlation id, but if you need an unguessable capability link or a password-reset token, reach for a dedicated generator instead. The earlier warning about Math.random applies here as well: a naive implementation that builds a v4 from a non-cryptographic source can be predicted, and nothing in the UUID spec stops it from doing so.

Why v4 can slow your database

This is the most overlooked point. Most relational databases index the primary key in a B+ tree, and new rows are inserted at the position set by the key.

• Auto-increment integer: new rows always append at the end, so pages fill and new pages open in order — sequential writes, cache-friendly.
• Random UUID (v4): a new row lands at a random position anywhere in the tree, causing random writes, frequent page splits and a lower cache hit rate. The index is also much larger (16 bytes versus 4 or 8). Because a secondary index stores a copy of the primary key alongside each entry, a wide primary key multiplies the storage and memory cost of every secondary index, not just the main one — which is why the bloat shows up most visibly there.
• Time-ordered UUID (v7): the first 48 bits are a millisecond timestamp, so new values increase monotonically. Insertion patterns approach auto-increment while keeping global uniqueness and unpredictability. Because the random tail still fills the remaining bits, two rows created in the same millisecond do not collide, and an observer cannot easily guess the next id the way they could with a plain counter.

So for a new system that wants a UUID primary key, v7 is a better default than v4. If you are already on v4 with large, write-heavy data, consider moving to v7 or ULID. ULID shares the thinking (time prefix plus random suffix); the difference is that ULID renders as 26 Crockford Base32 characters — human-readable and sortable.

Should you drop the hyphens

The hyphens are only a readability separator and carry no information. Removing them gives the 32-character compact form, about 11% smaller. Databases and URLs usually store the compact form and re-add hyphens only when showing it to a human. Note: do not compare case-sensitively — the hexadecimal A and a are the same value, so normalize case before comparing, or you will get the "looks identical but is not equal" bug.

This tool generates v1, v4 and v7, with optional uppercase, hyphen removal and batch counts. Generation uses the browser's cryptographically secure random source and runs entirely locally.