UUID Generator (v4 & v7)

v4 or v7 - the choice actually matters

A v4 UUID is 122 random bits. That is exactly what you want for anything that must be unguessable: a share link, a password-reset token, an identifier exposed to the public. It is also exactly what you do not want as a database primary key, because consecutive inserts land in random positions of the index, so each one dirties a different page and the hot part of the index never stays in cache. On a large, write-heavy table that is measurable write amplification rather than a theoretical concern.

A v7 UUID, standardised in RFC 9562 in 2024, puts a 48-bit millisecond timestamp in the high bits and fills the rest with randomness. Values therefore sort by creation time and inserts append to the end of the index, which is the behaviour you wanted from an auto-increment column without the coordination an auto-increment column needs. The trade is that a v7 leaks its creation time, so it is the wrong choice wherever v4's unguessability was the point.

• v4 for tokens, share links and any public identifier
• v7 for primary keys, event ids and anything sorted by time
• Nil and Max for sentinel values and range bounds
• Uppercase, braces and hyphen-free variants for .NET and char(32) columns

Where the randomness comes from

Values are drawn from crypto.getRandomValues, the browser's cryptographically secure generator. Math.random is never used, not even as a fallback, and if a platform has no secure source this tool reports an error instead of producing something. That is a deliberate refusal: a v4 built from a weak generator is indistinguishable from a good one by inspection, and somebody will eventually use it as a session token.

Nothing is generated on a server, so no identifier you take from this page has been transmitted, logged or seen by anyone else.

Inspecting one

Paste any UUID and the tool reports its version, its variant, and for a v7 the timestamp encoded in it, rendered as a real date. That last part is also the tool's own proof that the timestamp is really there rather than a claim in the copy.

What it will not do

It does not generate v1 or v6. Both encode a MAC address, which is a hardware identifier leaking out of an application identifier, and v7 supersedes both for the ordering property that was their only real advantage. It also does not generate v3 or v5, which are name-based hashes rather than random values and require a namespace argument that makes them a different tool.

It will not tell you whether two UUIDs came from the same generator, and it cannot verify that a v7's timestamp is honest - a timestamp is data, and data can be written by hand.