Password Generator

Length beats complexity, and it is not close

The number of possible passwords is the size of the character pool raised to the power of the length. Because the length is an exponent, increasing it multiplies the work an attacker has to do; increasing the pool only multiplies it by a small constant. This is why a 20-character password made only of lower-case letters, at about 94 bits, is far stronger than a 10-character password using every symbol on the keyboard, at about 65 bits.

In practice the choice is starker than that, because real attackers do not brute-force the whole space. They run dictionaries of leaked passwords, then apply transformation rules — capitalise the first letter, append a year, swap a for @. A password like `Summer2024!` sits at the centre of that rule set and falls almost immediately despite looking varied. A long string of random characters has no structure for a rule to exploit, which is the actual reason to prefer it.

So the honest advice is: pick the longest password the system will accept, and only then worry about which character types to include. If a site caps you at 12 characters — some still do, and some silently truncate anything longer — that is a real limitation on your security, and it is worth knowing it rather than assuming a longer password is being used.

Where the randomness comes from, and why the source matters

This tool uses `crypto.getRandomValues`, the browser’s interface to the operating system’s cryptographic random number generator. It is seeded from hardware events the system treats as unpredictable, and its output is not reproducible even if you know everything else about the machine.

The alternative, `Math.random`, is a general-purpose generator designed to be fast and statistically flat, not to be unguessable. Given a few outputs, its internal state can be reconstructed and every subsequent value predicted. A password generator built on it produces passwords that look perfectly random in the browser and are trivially predictable to anyone who has seen a few of them. This is not a theoretical concern; generators of that kind have shipped.

There is a second, subtler problem that a careless implementation gets wrong even with a good random source. If you take a random byte and reduce it modulo the size of the character pool, the characters near the start of the pool come up slightly more often whenever the pool size does not divide 256. For a 62-character pool, eight characters get one extra chance in 256. The bias is small — it costs a fraction of a bit of entropy — but avoiding it costs nothing: generate a byte, and if it falls in the incomplete tail, throw it away and try again. That is what this page does.

One honest limitation: entropy is a property of the generation process, not of the resulting string. It cannot tell you that a password you typed in yourself is weak, because weakness there comes from being in a dictionary. A tool that shows you a green bar for `Tr0ub4dor&3` is measuring character classes, not strength.

Why “one of each” is not the safety feature it looks like

Many sites require at least one upper-case letter, one digit and one symbol. The rule exists, and the generator here honours it by default, but it is worth understanding what it does and does not buy you.

What it buys: almost nothing in terms of strength. Forcing at least one of each class removes from the space all the passwords that happen to use only one class — but those are a vanishing fraction of a long password’s possibilities. The measured effect on entropy is a rounding error, and the tool does not pretend otherwise.

What it costs: a predictable structure. Attackers know the rule exists, so their cracking rules assume every password has a symbol and a digit in it. Mandating a mixed password removes the possibility of stumbling into a strong all-lower-case passphrase that no rule set was built for — which is exactly the kind of password that ages well.

The rule is here because websites enforce it and a password you cannot submit is not a password. Use it, and put your trust in length and uniqueness instead. If a service lets you set a 24-character lower-case password and you are willing to type it, take it.

How long, for what, and the reuse problem

A rough way to set the bar. Around 40 bits is the point where an online attack against a rate-limited login becomes impractical; around 60 bits resists a determined offline attack on a well-protected hash; 80 bits and above is comfortably beyond what brute force can reach with anything resembling current hardware. This tool labels the strength against those three numbers rather than inventing its own scale.

For anything that can reset your other accounts — your email, your bank, your password manager’s master password — aim at 80 bits or more, which at a 90-character pool means 13 characters and up. For a shop account you use twice a year, 60 bits is plenty. For a Wi-Fi password, length matters for a different reason: a long random string is impractical to type on a phone, let alone a television remote, which is the argument for setting a long password once and using a QR code to join.

The uncomfortable truth is that all of this is secondary to reuse. The overwhelming majority of account compromises do not crack anybody’s password; they take a password that leaked from one breached site and try it on every other site. A 12-character unique password is dramatically safer than a 30-character one used in five places. If you take one thing from this page, take that, and let a password manager handle the part where every account gets its own.

One last practical trap: a few systems cap passwords at lengths far below what you would choose, or truncate silently at 20 or 64 characters. Some older hashing setups truncate at 72 bytes. If a site rejects a long password, do not assume your long password is in use — it may have been cut off. And if two different long passwords behave identically at a login, that is a sign the site is silently truncating.

Passwords, passphrases, and what this tool will not do

A random character string is optimal for a machine to store and awful for a person to remember, which is why password managers exist. The practical arrangement for most people is one long master passphrase, memorised, plus randomly generated passwords for everything else, stored in the manager. Nothing generated on this page needs to be memorable, and nothing generated here should be.

If you do need something memorable, a passphrase is the better shape: four or five unrelated words from a large list. Five words drawn from a 7,777-word list is about 64 bits, and it survives the “write it on a sticky note” test far better than `x7#Kq2!vLm9`. The catch is that the words must be chosen randomly, not invented — a vivid image you came up with yourself is drawn from a much smaller space than a dictionary, and “correct horse battery staple” only works because the words were drawn by a generator.

What this page deliberately does not do is score the password you just typed in. A meaningful strength check for human-chosen passwords needs a list of millions of real leaked passwords plus the rule sets attackers apply, which is what zxcvbn and similar libraries ship — several hundred kilobytes of data. Without it, any score would be guesswork dressed up as analysis. If you want a verdict on a password you invented yourself, use a checker that bundles that data, and assume the honest answer is worse than it looks.

It also keeps no history. There is no “recently generated” list, because a list of passwords sitting in a browser tab is a liability with no upside. Once you navigate away, what was generated here is gone.