Pick a version (random v4 or time-ordered v7) and a count, and get UUIDs built from your browser's cryptographic random source. Uppercase and no-hyphen formats are supported, and nothing leaves the page.
v4 fills 122 bits from crypto.getRandomValues — not Math.random — so the values are safe against prediction and collisions.
v7 puts the Unix-millisecond timestamp in the first 48 bits, so lexicographic order is creation order — good for primary keys that should not fragment the index.
Generation and copying happen entirely in the browser with no network request, so the values never appear in any log.
A UUID (universally unique identifier) is a 128-bit identifier written as 32 hex digits grouped 8-4-4-4-12: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. The current standard is RFC 9562.
The point is uniqueness without a central authority: IDs minted on any server, client or offline device can be merged into one database later without colliding.
Each hex digit carries 4 bits, so 32 digits = 128 bits, of which 6 bits mark the version and variant.
v4 is entirely random (122 bits). The value carries no information, so it reveals neither when nor in what order it was created — right for externally visible IDs where guessability matters.
v7 stores the creation time (Unix milliseconds) in the first 48 bits, with 74 random bits after it. Sorting the strings sorts by time, which makes v7 the better database primary key — random v4 keys insert at random positions and fragment a B-tree index.
The trade-off: a v7 value exposes its creation time. Where that leaks something, use v4.
The v4 random space is 2¹²² ≈ 5.3 × 10³⁶. A billion UUIDs per second for a hundred years keeps the probability of even one collision below one in a million (birthday-paradox math).
In practice a UUID collision means a broken random generator, not bad luck.
Which is why UUIDs must never come from a predictable source like Math.random. This tool only uses crypto.getRandomValues.
RFC 9562 specifies lowercase output while requiring parsers to accept uppercase, so A1B2… and a1b2… are the same UUID — normalise before comparing.
Hyphens exist for human eyes. Where characters are expensive — database columns, URLs, file names — the 32-character no-hyphen form works too (this tool's «remove hyphens» option). For storage itself, 16 raw bytes (PostgreSQL's uuid type) beat the 36-character string by more than half.
Some systems, notably classic Microsoft GUID notation, wrap the value in {…} braces — same value, different packaging.
v1 combines a timestamp with the machine's MAC address. Exposing the generating device turned out to be a privacy problem, and v7 delivers the same sortability without it.
v3/v5 are not random at all — they hash a name (MD5 and SHA-1 respectively), so the same input always yields the same UUID. Useful when you need a deterministic ID for, say, a URL — more a calculator than a generator.
So an online generator really only needs v4 and v7: random IDs from v4, sortable IDs from v7 — between them nearly every use case is covered.
It fills 16 bytes from crypto.getRandomValues and overwrites only the version and variant bits defined by RFC 9562.
For v7 the Date.now() millisecond value goes into the first 48 bits big-endian — within the same millisecond, order falls to the 74 random bits, so pair it with a database sequence if you need strict monotonicity.
Generated values are never transmitted. Everything happens in the browser and vanishes when you leave the page.
When in doubt, v4 — the standard random UUID that works everywhere. If the values must sort by creation time, like database primary keys or event IDs, v7 keeps the index compact.
In theory, but not in practice. A v4 UUID has 122 random bits — generating a billion per second for a century leaves the chance of a single collision far below one in a million.
No. They are built from the browser's cryptographic generator with no network request, and they disappear when you leave the page.