PassGenFast

For developers

UUID generator

Version 4 UUIDs, drawn from the same cryptographic source as everything else here. One at a time or a batch, ready to paste.

Generator

  • Generating…
How many
Version 4, RFC 9562
Random rather than time or MAC based, so it gives away nothing about the machine that made it.
122 bits of randomness
Six of the 128 bits are fixed for the version and variant, which is why it is not 128.

Generated in your browser with crypto.getRandomValues. Nothing is sent to us, and the page keeps working with your connection switched off.

What the characters mean

A UUID looks like an arbitrary string of hex, but two positions are fixed. Take 3f2a91c4-8b7d-4e21-9c05-71ad3e9f0b28:

  • The third group always starts with 4. That is the version, and it says this UUID was made from random bits rather than from a clock or a MAC address.
  • The fourth group always starts with 8, 9, a or b. That is the variant, two fixed bits saying which UUID layout is in use.

Those six fixed bits are why a v4 UUID carries 122 bits of randomness rather than 128. It is a small difference and it makes no practical odds, but it is the sort of detail worth getting right rather than rounding up.

Identifiers, not secrets

A UUID is designed to be unique, not to be unguessable, and the distinction matters in practice. Unique means two systems can generate identifiers independently and never clash. Unguessable means the value can stand between an attacker and someone’s data. A v4 UUID happens to be both, because it is random — but everything around it treats it as an identifier.

That is where the trouble starts. Identifiers end up in server logs, in analytics, in URLs that get shared and in screenshots pasted into tickets. A value used as a password reset token should never be somewhere that happens to. If you want a secret, generate one on purpose with the random string generator and handle it like a password.

Uniqueness in practice

122 random bits is roughly 5.3 undecillion possibilities. The usual way to picture it: you would have to produce a billion UUIDs every second for about 86 years before the chance of any two matching reached a coin flip. In other words, generate all you like — collisions are not the thing that will go wrong with your system.

Where they come from here

Sixteen bytes from crypto.getRandomValues, then the version and variant bits are set, then the bytes are formatted as hex. No time, no counter, no machine identifier, and no network request. If the browser cannot provide a cryptographic random source, the page refuses to generate anything rather than fall back on something predictable.

Password generator

The main tool: random characters, any length, with an honest strength readout.

Passphrase generator

Real words you can actually remember, for the passwords you have to type by hand.

Username generator

Word pairs and invented handles for gaming, social and sign-ups.

Random string generator

Keys, tokens, salts and test data, without composition rules getting in the way.

PIN generator

Random digits for a card or a lock, with an honest note on how little a PIN protects.

General information, not security advice for your particular situation. Last reviewed August 12, 2026.

Answers

Frequently asked questions

What kind of UUID is this?

Version 4, the random one. All 128 bits start out random, then six of them are overwritten to record the version and the variant, leaving 122 bits of actual randomness. Unlike version 1, it contains no timestamp and no network card address, so it gives away nothing about the machine or the moment that produced it.

Source: RFC 9562, UUID version 4

Are these safe to use as secrets?

They come from the browser's cryptographic random source, so the randomness itself is sound, and 122 bits is far beyond guessing. The caution is about habit rather than strength: UUIDs get logged, put in URLs and pasted into tickets, because most of them are identifiers rather than secrets. If you need a bearer token, generate one deliberately with the random string generator and treat it as a secret from the start.

Will two of these ever collide?

Not in any practical sense. With 122 random bits you would need to generate a billion a second for about 86 years before a collision became more likely than not. Every batch on this page is checked for uniqueness in our tests as a sanity check on the implementation, not because collisions are a real risk.

Why not just use crypto.randomUUID()?

It is a perfectly good function and it uses the same underlying randomness. We build the value from getRandomValues instead so that this page has exactly one random source to audit, and because getRandomValues works in a few contexts where randomUUID is unavailable. The output is identical in format and in strength.

Do the UUIDs ever reach your server?

No. They are generated on your device, and the page never sends them anywhere. That is also why the list is fresh on every load rather than served from a cache: two visitors must never receive the same values.