UUID generator that never touches Math.random

In theory yes, in practice no. A version 4 UUID carries 122 random bits — six of the 128 are spent marking the version and the variant — which is about 5.3 × 10^36 possible values. By the birthday bound you would need roughly 2.7 × 10^18 of them before there was a 50% chance that any two matched, and at a million UUIDs per second that takes about 86,000 years. The realistic failure is never the arithmetic, it is a weak random source, which is why this page uses the Web Crypto API and stops rather than falling back to Math.random().

Usually yes, if you were going to use a UUID for the key at all. Version 7 leads with a 48-bit Unix millisecond timestamp, so new rows land at the right-hand edge of a B-tree index instead of scattering across every page of it — the random insertion pattern of a v4 primary key is what fragments pages, inflates write amplification and pushes the index out of cache. Two caveats: a v7 publishes its creation time to the millisecond, and a monotonic key concentrates writes on one page, which matters once you shard.

No — treat it as an identifier, never as a credential. A v4 is unguessable enough to act as an unlisted URL, but it travels in Referer headers, browser history, proxy logs and analytics pipelines, and nothing in the format resists enumeration if any part of it turns out to be predictable. Versions 1, 6 and 7 are weaker still, because their timestamp is readable by anyone who pastes the value into the decoder above.

Nothing meaningful — GUID is Microsoft's name for the same 128-bit value. The one real trap is byte order: Microsoft's binary GUID struct stores the first three fields little-endian, so the same identifier written to a Windows GUID and to an RFC 9562 byte array produces two different byte sequences even though the text forms are identical. Microsoft tooling also wraps the text in braces, which the Wrap control adds for you.

122, not 128. Four bits are pinned to 0100 to mark version 4 and two more to 10 to mark the RFC 9562 variant, which is why the 13th hexadecimal digit of every v4 is 4 and the 17th is 8, 9, a or b. Those six bits are exactly what lets a parser tell one version from another, so reducing a UUID to 32 arbitrary hex digits quietly produces something that is no longer a UUID.

Because it is only exposed in a secure context — HTTPS, or localhost. Open the same page over plain http:// from a LAN address and crypto.randomUUID() disappears along with crypto.subtle, while crypto.getRandomValues() stays available; that is the fallback this generator uses, and the status line under the output names whichever one produced your batch. If neither exists the page generates nothing and says so, because Math.random() is a fast non-cryptographic PRNG whose internal state can be reconstructed from a short run of outputs.

It can, and historically it did — the author of the 1999 Melissa virus was identified partly through GUIDs that Word had embedded in documents. RFC 9562 still permits a real MAC address in the 48-bit node field, but it also permits a random node with the multicast bit set, and that is what this page emits: a browser cannot read your MAC anyway, and a fresh random node is drawn for every batch. The decoder tells you which kind you are holding — if the first byte of the node is odd, the multicast bit is set and the node is random.