UUID v4 Generator
Generate cryptographically random version-4 UUIDs, copy or download them, and inspect any UUID to check its version and variant. Everything runs in your browser.
About this tool
UUIDs are generated with crypto.getRandomValues, the browser's cryptographically secure random source — not Math.random — and the version nibble and variant bits are set exactly as RFC 4122 requires for version 4. The inspector works in reverse: it validates the canonical 8-4-4-4-12 format, reads the version nibble to tell you which UUID version it is (v1 time-based through v8 custom), and decodes the variant bits.
Everything happens locally in your browser with plain JavaScript. Generated UUIDs and anything you paste into the inspector are never sent to a server — there is no upload, no storage, and no tracking of tool inputs, so it's safe to inspect identifiers from private systems.
Frequently asked questions
Can two v4 UUIDs collide?
In theory yes, in practice no. A v4 UUID has 122 random bits, so by the birthday bound you would need roughly 2.7 quintillion UUIDs — about a billion per second for 86 years — before the odds of a single collision reach 50%. For any realistic system the collision risk is far below the chance of hardware error, which is why v4 UUIDs are generated without any coordination.
What is the difference between UUID v1, v4, and v7?
v1 encodes a timestamp plus (traditionally) the machine's MAC address — sortable-ish, but it leaks when and where it was made. v4 is 122 bits of pure randomness, the default choice for opaque identifiers. v7, standardized in RFC 9562 (2024), puts a 48-bit Unix millisecond timestamp first and randomness after: IDs sort by creation time, which makes database B-tree indexes much happier than random v4 keys. Use v7 for primary keys, v4 when creation time must stay hidden.
Are UUIDs safe to use as session tokens or secrets?
Prefer not to. RFC 9562 explicitly warns against assuming UUIDs are unguessable. A v4 UUID from a CSPRNG carries 122 bits of entropy, which sounds fine, but many UUID implementations are not cryptographically random, and UUIDs leak into logs and URLs by convention. For secrets, generate a dedicated random token — the Secure Password Generator on this site produces crypto-random strings with the entropy math shown.
Is Math.random() good enough for generating UUIDs?
No. Math.random() is not cryptographically secure and its internal state can be recovered from observed outputs, making "random" UUIDs predictable — and poorly seeded generators have produced real-world collisions. This tool uses crypto.getRandomValues, the same CSPRNG behind the standard crypto.randomUUID(), so the version and variant bits are set per RFC 4122 over genuinely unpredictable bytes.
What do the 4 and the 8, 9, a, or b in a UUID mean?
They are the only non-random parts. The first hex digit of the third group is the version (4 = random), and the first digit of the fourth group encodes the variant — binary 10xx, so hex 8, 9, a, or b — marking the RFC 4122/9562 layout. That leaves 122 of the 128 bits random. The inspector on this page reads both fields for any UUID you paste.