Free UUID Generator

How it works

1. Choose v4 for a fully random identifier, or v7 if the ID will be a database key and you want it to sort by creation time.
2. Set how many you need — up to 500 in one go.
3. Adjust the format: uppercase, hyphens on or off, or braces for the Windows registry style.
4. Copy the whole list to your clipboard, or download it as a plain text file.

Should you use v4 or v7?

v4 is 122 random bits and nothing else. It carries no information about when or where it was made, which makes it the right default for anything user-facing — session tokens, file names, public URLs, correlation IDs in logs.

v7 puts a 48-bit millisecond timestamp at the front, then randomness. Because the timestamp comes first and is stored big-endian, sorting v7 UUIDs as text puts them in the order they were created.

That ordering is the reason v7 exists. Database indexes are B-trees, and they are happiest when new keys land at the right-hand edge. Random v4 keys scatter inserts across the whole index, splitting pages and evicting cache; the index grows larger and writes get slower as the table does. v7 keys append in order, so the hot pages stay hot.

The short version: if the UUID is a primary key, use v7. If it is exposed to users and you would rather not publish when the record was created, use v4.

Nothing leaves your device

The values are produced by your browser’s own cryptographic random number generator — the same one used for TLS keys — through the Web Crypto API. There is no server call, so no identifier you generate here is ever seen by us or by anyone else. Once the page has loaded, the tool keeps working offline.

Common questions

Are these safe to use in production?

Yes. They come from the platform’s cryptographically secure random number generator, not from Math.random(), so they are unpredictable as well as unique. Generating them in your browser rather than on our server also means no third party has ever seen them.

Could two UUIDs ever be the same?

In practice, no. A v4 UUID has 122 random bits, which is roughly 5.3 × 10³⁶ possibilities. You would need to generate a billion UUIDs every second for about 85 years before reaching a 50% chance of a single collision anywhere in that set. For v7, uniqueness within the same millisecond rests on 62 random bits plus a sequence counter, which is comfortably beyond any realistic generation rate.

Does v7 reveal when the ID was created?

Yes, and this is worth thinking about. Anyone holding a v7 UUID can read its creation time to the millisecond. That is usually harmless for an internal primary key, but if the ID appears in a public URL it publishes a timestamp — enough to infer signup times, order timing, or how busy a service was. Use v4 where that matters.

UUID or a plain auto-increment integer?

An integer is smaller (4–8 bytes against 16), faster to join on, and easier to read aloud. A UUID can be created anywhere — in the browser, in another service, on an offline device — without asking a central database for the next value, which is what makes it worth the extra bytes in distributed systems. It also avoids leaking your row count, which a sequential ID in a URL does.

Are v7 UUIDs generated here in strict order?

Yes. Generating 500 at once happens well inside a single millisecond, so the timestamp alone could not order them. The tool follows the RFC 9562 monotonic method: a 12-bit counter advances within each millisecond, so a bulk batch is already sorted when you copy it.

Why only v4 and v7?

They are the two that answer real questions. v1 embeds the machine’s MAC address, which leaks hardware identity and is why it fell out of favour. v3 and v5 are deterministic hashes of a name — useful, but they need a namespace and an input, so a generator like this one cannot produce them for you. v7 supersedes v6 for new work.