Password Generator

Cryptographically secure passwords and passphrases, generated entirely in your browser. The page uses crypto.getRandomValues, the same random source the browser uses for TLS keys. Nothing you generate is sent anywhere. Disconnect your network and try it: still works.

Explain like I'm 5 (what even is this calculator?)

It rolls cryptographic dice and writes down what they land on. The dice are good ones (the same ones your browser trusts to keep your bank session safe), and the result never leaves the page. Pick how long you want it, hit Generate, copy it into your password manager, close the tab. Done.

Generate

Press Generate.

  • Entropy0 bits
  • Strength
  • Crack time (offline fast hash, 10B/s)

Generated locally with crypto.getRandomValues. The password never leaves your browser. Disconnect your network and try it: still works.

Prove it

Entropy bits = log2(charset size) × length for random passwords, or log2(wordlist size) × words for passphrases. Crack time assumes 10 billion guesses per second (a well-funded offline attacker against fast hashes like NTLM or unsalted SHA1). Slow hashes (bcrypt, Argon2) push the figure several orders of magnitude further out.

Why this generator runs in your browser, and why that matters

A password generator that posts the password back to a server is precisely the thing you should be afraid of. Even when the operator has the best of intentions, the generated string has briefly existed on someone else's machine, in their logs, possibly in their backups. For a tool whose entire point is producing something nobody else should ever see, that is the wrong shape.

Everything on this page runs locally. The randomness comes from crypto.getRandomValues, which on every modern browser is wired into the operating system's cryptographic random source: the same thing your browser uses to negotiate TLS sessions with your bank. There is no server-side component. Open dev tools, watch the network tab, press Generate, and notice that nothing happens.

Why Math.random is dangerous for passwords

Most JavaScript random calls use Math.random. It is fast, fine for shuffling cards in a browser game, and totally unsuitable for anything an attacker might care about. The output is generated by a deterministic algorithm seeded once when the page loads. Given a handful of values, an attacker can recover the seed and predict every future call. There are published proofs of concept that pull this off in milliseconds.

Cryptographic random (which is what this page uses) is held to a different standard. The output is required to be indistinguishable from true randomness by any computationally bounded observer. That is not a marketing claim, it is the formal definition the algorithm has to satisfy to be allowed to call itself a CSPRNG.

What entropy actually means

Entropy, in the password sense, is just a measurement of how many guesses an attacker would need on average to find your password by brute force. It is expressed in bits because each bit doubles the work. A 40-bit password takes a trillion-ish guesses. A 60-bit password takes a quintillion. An 80-bit password is well past the point that any individual attacker can plausibly throw at it, and a 100-bit password is fine for the rest of your career.

For a random password, the maths is straightforward: log2 of the charset size, multiplied by the length. A 16-character password drawn from the 94 printable ASCII symbols carries about 105 bits. The same length drawn from only lowercase letters carries about 75. That is a real, exploitable gap.

When passphrases beat random strings

Passphrases shine when you have to type the password yourself. Master passwords for password managers, full-disk encryption keys, laptop login. A five-word passphrase from a 500-word list carries roughly 45 bits, which is fair-to-strong, and you can type it without misspellings or shoulder-surfing accidents. Random characters, by contrast, are denser per symbol but miserable to type. For anything that lives in a password manager and gets auto-filled, random wins. For anything you have to type, lean passphrase.

A note on the crack-time figure

The page shows estimated crack time at 10 billion guesses per second. That is a reasonable shorthand for a well-funded offline attacker against a fast hash like NTLM or unsalted SHA1. Modern password storage uses slow hashes (bcrypt, scrypt, Argon2) which are deliberately tuned to take milliseconds rather than nanoseconds, pushing the figure several orders of magnitude further out. Treat the number on the page as the worst case.

Related calculators

A random password is one shape of credential. These cover the rest.

Frequently asked questions

Is this password generator safe to use?

Yes. Everything runs in your browser using the Web Crypto API. The page never sends your generated password back to a server, and there is no server-side component to log it. Verify by opening dev tools, going to the network tab, and pressing Generate. Or pull the network cable. It still works.

What is entropy?

Entropy measures how unpredictable a password is, expressed in bits. Each bit doubles the average work an attacker has to do. Under 40 bits is weak, 60 is fair, 80 is strong, 100 plus is overkill for almost anything that is not nation-state attention.

Why use crypto.getRandomValues instead of Math.random?

Math.random is fast and fine for shuffling cards in a browser game, but its output is predictable. Given a few values, an attacker can reconstruct the seed and predict every future call. crypto.getRandomValues uses the operating system's cryptographic random source, which is suitable for keys and passwords.

When should I use a passphrase instead of a random password?

Use a passphrase when you have to type the password: laptop login, password manager master password, full-disk encryption. For anything that lives in a manager and gets auto-filled, random characters win on entropy per character.

How long does it take to crack one of these passwords?

The page shows estimated crack time at 10 billion guesses per second, the rough rate of a well-funded attacker against fast hashes. Slow hashes (bcrypt, Argon2) push the figure several orders of magnitude further out. Treat the displayed time as a worst case.