Cryptographically secure v4 UUIDs, no Math.random
A UUID (Universally Unique Identifier) is a standardised 128-bit identifier defined by RFC 9562, which superseded the older RFC 4122. Version 4, the one this tool generates, fills the value with random bits except for 4 fixed bits that mark the version and 2 that mark the variant, leaving 122 truly random bits. In the browser those bits come from the Web Crypto API (crypto.randomUUID or crypto.getRandomValues), which uses the operating system's cryptographic generator, never Math.random. The result is written as 32 hexadecimal digits grouped as 8-4-4-4-12, for a total of 36 characters with the hyphens. With 122 bits of entropy, the chance of two generations colliding is statistically negligible even at global scale, which makes UUID v4 a common choice for primary keys, session tokens and resource identifiers in REST APIs, without needing a central server to coordinate the IDs.
A UUID occupies 128 bits, represented as 32 hexadecimal digits in the 8-4-4-4-12 layout. In v4 almost everything is random: only 6 bits are fixed. Four of them mark the version, which is why the 13th hex digit is always 4, and two mark the RFC 4122 variant, which forces the 17th digit to always be 8, 9, a or b. Subtracting those 6 bits leaves 122 bits of real entropy.
That design is what lets you generate unique identifiers with no central coordination. Because each machine draws 122 bits independently, there is no need for a database or service that hands out IDs, two different systems can generate UUIDs at the same time with collisions practically impossible.
Example 1, dissecting a value. In 3f2504e0-4f89-41d3-9a0c-0305e82c3301, the version digit (the first of the third group) is 4, confirming a v4; the first digit of the fourth group is 9, a valid RFC 4122 variant. The validation tab does exactly this reading: it checks the 36-character format, extracts the version and variant and rejects any string outside the pattern.
Example 2, the collision odds in numbers. By the "birthday paradox", you would need about 2.71 × 10¹⁸ (2.71 quintillion) v4 UUIDs to reach a 50% probability of a single collision. Generating 1 billion UUIDs per second, it would take roughly 85 years just to reach that mark, in practice, no production collision has ever been documented.
UUID v4 is great when you need a unique, unpredictable identifier generated on the client: log correlation tokens, file names, idempotency keys and resource IDs in APIs. Because they are random, they also make it hard for anyone to guess or enumerate sequential IDs, which helps with security.
The known limit shows up as a primary key in relational databases: being fully random, v4 scatters inserts across the B-tree index and causes fragmentation, worse than sequential IDs. For write-heavy workloads, UUID v7 (also in RFC 9562) or ULID embed a timestamp at the start and preserve chronological ordering. Here, all generation is local: the UUIDs never leave your browser, and a batch can be exported as TXT or JSON.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/uuid-generator"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="UUID Generator"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
A UUID v4 is a 128-bit unique identifier generated with random bits, except for the 4 version bits and 2 variant bits, which leaves 122 truly random bits. The format is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where the version digit is always 4 and y is 8, 9, a or b.