Every password generator produces something that looks random. Whether it is random depends on which source of randomness it used, and that difference is invisible in the output. Two generators can both hand you k7Rm2xQp9wLz-shaped strings while one is genuinely unpredictable and the other is reproducible by anyone who knows roughly when you clicked the button.

The Password Generator runs in your browser using the Web Crypto API, and nothing it produces leaves your device.

The distinction that matters

Programming languages ship two kinds of random number generator.

Ordinary PRNGs — JavaScript's Math.random(), PHP's rand(), Python's random module — are designed to be fast and statistically well-distributed. They are not designed to be unpredictable. Given enough output, their internal state can be recovered, and from there every future value is known. They are perfectly good for shuffling a playlist and completely unsuitable for anything secret.

Cryptographically secure generators — crypto.getRandomValues() in the browser, random_bytes() in PHP, secrets in Python — draw from the operating system's entropy pool. Output cannot be predicted even by someone who has seen a great deal of previous output.

For a password, only the second kind counts. A generator built on Math.random() is not a security tool, however convincing its output looks.

The modulo bias trap

Even with a secure source, it is easy to introduce bias.

The naive approach is to grab a random byte (0–255) and take byte % charset.length. With a 62-character set, 256 does not divide evenly by 62: values 0–61 appear four times across the byte range, but 62–67 appear five. Some characters become measurably more likely than others.

It is not a catastrophic weakness, but it is a real reduction in entropy, and it is entirely avoidable — you reject values that fall outside the largest clean multiple and draw again. Worth knowing, because plenty of hand-rolled generators get this wrong.

How long

If a password manager is typing it for you, length is free. Use it.

  • 16 characters from a mixed set — around 95 bits. Fine for most accounts.
  • 20–24 characters — 120–150 bits. Sensible default for anything that matters.
  • 32 characters — well past the point where the password is the weak link.

Beyond roughly 128 bits you are protecting against nothing real. An attacker will phish you, breach the service, or steal a session cookie long before brute force becomes worthwhile. Extra length past that point is cost without benefit.

The symbols problem

Symbols add entropy per character, and they also break things.

Some login forms silently truncate at a length limit they do not disclose. Some strip characters they consider dangerous. Occasionally a system stores the full password but compares only the first few characters. You discover this when a password that worked yesterday does not work today, and you cannot tell why.

The pragmatic approach: use alphanumeric-only at greater length for systems you do not trust, and the full character set at 20+ characters everywhere else. Four extra characters more than compensates for dropping symbols, and it sidesteps every input-handling bug you cannot see.

Generating in the browser is the safe option

A password generated on a remote server has been transmitted over a network and existed in that server's memory, possibly its logs. You have no way to verify what happened to it.

A generator using crypto.getRandomValues() in your own browser never transmits anything. You can verify this directly: open the network tab, generate a password, and watch no request go out. That is the property to look for — in our tool and in anyone else's.

What to do with it once generated

A strong unique password per site is only workable with a password manager, because nobody memorises forty random strings. That is the actual reason reuse is so common — not laziness, but an impossible memory task.

You need to memorise exactly two things: the master password for your manager, and your device unlock. Everything else the manager holds. Make those two a long random passphrase, turn on two-factor authentication, and the problem is solved.

And do not email or message a generated password to yourself "temporarily". That copy will outlive your intentions.

Common questions

Is Math.random() safe for passwords?
No. It is predictable by design. Use crypto.getRandomValues() or your language's cryptographic equivalent.

How long should a generated password be?
20–24 characters if a manager stores it. Beyond about 128 bits of entropy you gain nothing practical.

Should I include symbols?
Usually yes, but some systems mishandle them silently. Alphanumeric at greater length is a safe fallback.

Are browser-based generators secure?
They can be more secure than server-side ones — nothing is transmitted. Check the tool makes no network request when generating.

Where to go next