UUID Generator

How it works

1. 1Pick a version, say how many you need, and they are generated in your browser.
2. 2Version 4 is entirely random. Version 7 puts a millisecond timestamp in the leading bits, so the ids sort by creation time.
3. 3Uppercase and brace formatting are there for the systems that insist on them — .NET and SQL Server, mostly.
4. 4The inspector reads any UUID back: its version, and for a v7 the exact moment it was created.

Common questions

Should I use v4 or v7?

v7 if the UUID will be a database primary key. Random v4 keys scatter inserts across the whole index, which fragments it and hurts write performance as the table grows. v7 ids are time-ordered, so new rows land together at the end. Use v4 when you specifically do not want the creation time to be readable.

Does a v7 UUID leak information?

Yes — the creation time, to the millisecond. That is the trade. If a UUID is exposed publicly and knowing when a record was created would tell someone something, use v4.

Are these actually random?

They come from crypto.getRandomValues, your browser’s cryptographically secure random source — not Math.random, which is predictable from a handful of outputs and should never be used for identifiers.

Can two UUIDs collide?

In theory. In practice a v4 UUID has 122 random bits; you would need to generate roughly a billion per second for 85 years to have a 50% chance of one collision. It is not the thing to worry about.

What happened to v1 and v5?

v1 embeds the machine’s MAC address, which is a privacy problem and why it fell out of use. v5 hashes a name into a namespace, so it is deterministic rather than random — useful, but a different job from generating fresh ids.