UUID Generator
Generate random v4 or timestamp-based v1-style UUIDs in bulk, with uppercase and hyphen options.
About the UUID Generator
UUIDs come out RFC 4122-compliant version 4, generated with the browser's built-in crypto.randomUUID() when it's available, falling back to a manual crypto.getRandomValues implementation on older browsers. The v1-like option produces a timestamp-based UUID structurally similar to real v1 without needing actual hardware MAC address data, and none of it touches a server.
Why only 122 of a v4 UUID's 128 bits are actually random
A UUID is 128 bits, but not every bit gets to be random. The fallback implementation here explicitly sets two small groups of bits after generating raw random bytes: bytes[6] = (bytes[6] & 0x0f) | 0x40 forces the top nibble of that byte to 4, marking the UUID as version 4, and bytes[8] = (bytes[8] & 0x3f) | 0x80 forces the top two bits of that byte to 10, marking it as the standard RFC 4122 variant. Those six fixed bits are what let any system recognize "this is a version 4, RFC 4122-variant UUID" just by inspecting the string, and they're also exactly why the commonly cited figure for v4 randomness is 122 bits, not the full 128.
Just how unlikely a collision actually is
Even with "only" 122 random bits, the collision odds are effectively negligible for any realistic use. Following the birthday-paradox math that applies to random identifiers, you'd need to generate somewhere around 2.71 quintillion (2.71 × 10^18) random v4 UUIDs before the probability of even one accidental collision anywhere in that entire set reaches just 50%. That's a large enough number that in ordinary application use, generating unique IDs for database rows, session tokens, or file names, treating v4 UUIDs as effectively guaranteed-unique is a completely reasonable assumption.
Why the "v1-like" option is honestly labeled, not called real v1
A genuine RFC 4122 version 1 UUID encodes a 60-bit timestamp counted in 100-nanosecond intervals since October 15, 1582 (the date the Gregorian calendar began, an intentionally arbitrary historical reference point chosen by the original UUID specification), plus the actual hardware MAC address of the generating machine in its final 48 bits. This tool's version deliberately differs on both counts: it uses Date.now(), standard millisecond-precision, Unix-epoch-based JavaScript time, rather than the exact spec's finer-grained, differently-dated timestamp, and it fills the "node" portion with random bytes instead of a real MAC address. That second substitution is a deliberate, safer choice, real v1 UUIDs embedding an actual hardware MAC address have long been recognized as a privacy concern, since that portion of the ID can be used to fingerprint or trace back to the specific physical machine that generated it. Calling this option "v1-like" rather than claiming full v1 compliance is simply an honest reflection of those two intentional differences.
The clock sequence field reuses the same variant-marking trick
The v1-like generator's clock sequence bytes go through the identical bit-masking pattern used for the v4 variant marker, randomByte() & 0x3f | 0x80, forcing the top two bits to 10 for the same RFC 4122 variant reason. It's the same underlying technique, clear specific bits, then set specific bits, applied a second time in a different part of the UUID, which is why both UUID versions this tool generates carry a consistent, correctly-marked RFC 4122 variant field regardless of which version you pick.
Why the Quantity field caps at 50
Bulk-generating UUIDs is genuinely cheap computationally, the 50-item cap here isn't a performance safeguard so much as a practical UI choice, keeping the output list readable and easy to scan or copy in one glance rather than scrolling through an unwieldy wall of identifiers. If a workflow genuinely needs thousands of UUIDs at once, generating them programmatically with a script is a better fit than a browser-based one-click tool designed around quick, visual, manual use.
Frequently Asked Questions
Why are only 122 of a UUID's 128 bits actually random?
Six specific bits are deliberately fixed rather than random: four bits mark the UUID version (like "4" for version 4) and two bits mark the RFC 4122 variant. These fixed bits let any system recognize the UUID's type and format just by inspecting the string.
How likely is it that two generated v4 UUIDs will collide?
Extremely unlikely, following birthday-paradox math, you'd need to generate roughly 2.71 quintillion random v4 UUIDs before the probability of even one collision reaches 50%. For any realistic application use, treating v4 UUIDs as effectively guaranteed-unique is entirely reasonable.
Is the "v1-like" option a real, spec-compliant version 1 UUID?
No, and it's deliberately labeled to reflect that. Real v1 uses a 100-nanosecond-precision timestamp since 1582 and an actual hardware MAC address, while this tool uses standard JavaScript millisecond timing and random bytes instead of a MAC address.
Why doesn't the v1-like option use a real MAC address like the original spec?
Embedding a genuine hardware MAC address in a UUID is a recognized privacy concern, since that portion of the ID can potentially be used to fingerprint or trace the specific machine that generated it. Using random bytes instead avoids that leak while keeping the same structural format.
Does this tool use the browser's native UUID generation when available?
Yes, for version 4 it calls crypto.randomUUID() directly when the browser supports it, only falling back to a manual implementation using crypto.getRandomValues() on older browsers that lack native support.
Is my generated UUID sent anywhere?
No, generation happens entirely in your browser using the Web Crypto API. Nothing is transmitted to a server, whether you generate one UUID or the maximum of 50 at once.