UUID v4 Generator

What is UUID v4?

UUID v4 fills 122 of its 128 bits with random data (the remaining 6 bits mark the version and variant). Because the value is purely random, no information about when or where it was created can be inferred from it — a privacy advantage over timestamp-based versions.

When should I use v4?

Use v4 whenever you just need a unique identifier: request IDs, session tokens' identifiers, resource IDs in APIs, file names. If your IDs will be used as database primary keys and insert order matters, consider UUID v7 instead — its time-ordered layout keeps database indexes efficient.

How likely is a collision?

With 122 random bits, you would have to generate roughly 2.7 quintillion UUIDs to reach even a 50% probability of one collision. For practical purposes, v4 UUIDs can be treated as globally unique.

Is UUID v4 truly random?

UUID v4 is random in every bit that carries information: 122 of its 128 bits come from a random source, and the remaining 6 encode the version and variant. Quality depends on the generator. Implementations that follow RFC 9562 draw from a cryptographically secure source — crypto.getRandomValues() in browsers, os.urandom() in Python, SecureRandom in Java — which makes output unpredictable even to an attacker who has seen many previous values. Libraries that fall back to a plain pseudo-random generator (an old Math.random() shim, for example) produce values that look random but can be predicted from prior output. This generator uses the Web Crypto API, so every UUID it creates is cryptographically secure and never leaves your browser.

Can I use UUID v4 as a database primary key?

You can, and many systems do, but at scale it costs you write performance. Because v4 values are uniformly random, consecutive inserts land at random positions in the primary key's B-tree index. That scatters writes across pages instead of appending to the rightmost one, causing page splits, extra I/O, and a working set too large to stay cached. On tables in the tens of millions of rows the difference against a sequential key is measurable. UUID v7 solves this while keeping every other property of a UUID: its leading 48-bit timestamp makes new values sort last, so inserts stay append-mostly. Keep v4 when the identifier is exposed publicly and the creation time must remain private.