Password Generator
Cryptographically random, generated in your browser, never sent anywhere.
Excessive. Well past the point of adding security. Extra characters here only make it harder to type.
Generated in your browser. Nothing is sent to a server, because there is no request to make: reload the page and these are gone for good.
How the Password Generator works
Set the length, choose which characters to draw from, and the password is built from your browser's cryptographic random source. Nothing is sent to a server, because there is nothing to send: the generation happens in the tab and the result disappears when you reload. The strength figure below the slider is entropy in bits, which measures how many possibilities an attacker has to cover rather than guessing at how a human chose it.
Also known as: strong password generator · random password generator · secure password maker · 16 character password generator · password generator no ads
Where the randomness comes from
Almost every password generator on the web is a few lines of JavaScript around Math.random. It looks fine. The passwords are unpredictable to a person watching. They are not unpredictable to somebody with a few of the previous outputs, because Math.random is not designed to resist that: in V8, the engine behind Chrome and Node, it is an xorshift generator with 128 bits of state, and there is published work showing that state can be recovered from a short run of outputs and the sequence run forwards and backwards from there.
That does not matter for shuffling a playlist. It matters a great deal for a generator that produces one password after another in the same tab, because an attacker who can observe any output has a route to the rest. The fix is not subtle: browsers expose crypto.getRandomValues, which draws from the operating system's entropy pool through the same path used to generate TLS keys, and it is what this tool uses. If the API is missing, the page says so and refuses rather than quietly falling back to something weaker.
This is the kind of difference that never shows up in a comparison of features, which is exactly why it is worth stating.
The bias hiding in the obvious implementation
Having good random bytes is only half of it. You then have to turn a byte into a choice from an alphabet, and the natural way to write that is to take a remainder: pick a random byte, take it modulo the number of characters, use the result as an index. It is one line and it is wrong.
Consider 62 characters, the usual mixed-case alphanumeric set. A byte holds 256 values. Divide 256 by 62 and you get four complete cycles with 8 left over, which means the first 8 characters of the alphabet can be reached 5 ways each while the other 54 can be reached 4 ways. Those first 8 come up about 25 percent more often than the rest. The passwords still look completely random, and the effective entropy is measurably lower than the advertised figure.
The correct approach is rejection sampling: work out the largest multiple of the alphabet size that fits inside the range you are drawing from, and throw away any value above it. That value gets redrawn rather than squeezed. It costs a negligible number of extra draws, under one in two billion for the ranges used here, and it makes the distribution exactly flat. Everything on this page goes through that path.
What the bits figure actually measures
The strength shown here is entropy in bits, computed as the length multiplied by the base-two logarithm of the alphabet size. Twenty characters from a 94-character set is about 131 bits. Each bit doubles the number of possibilities an attacker has to work through, so the gap between 60 and 80 bits is a factor of a million.
The important thing about this figure is that it describes the generator, not the string. A password drawn at random from 94 characters carries the same strength whether it comes out looking like line noise or, by pure chance, looking like a word. This is where the strength meters built into signup forms mislead: they inspect the characters you typed and try to infer how a human would have chosen them, which is a reasonable thing to do for a password a human chose and a meaningless thing to do for one a generator produced.
Where the thresholds sit is a judgement call, and it depends entirely on how the site stores your password. Against a slow hash such as bcrypt or Argon2 with sensible parameters, even 50 bits is a long way beyond feasible. Against an unsalted fast hash in a leaked database, 60 bits is not comfortable. NIST's own guidance in SP 800-63B pointedly declines to publish a table, which is why the wording here is hedged and the numbers are round.
Length, character classes, and the rules sites impose
Given a choice between a longer password and a more complicated one, take the length. Adding one character to a 26-letter password multiplies the search space by 26. Switching that same password to mixed case and digits multiplies it by roughly 2.4 per character, which is worth having but is not the same lever. This is why a long passphrase beats a short string of symbols, and why the sensible default here is twenty characters rather than twelve with everything switched on.
The option to force one character from each selected class exists because sites demand it, not because it helps. It costs a small amount of entropy, since it excludes every password that happens to contain no digit, and the loss is under a hundredth of a bit at twenty characters. Worth taking to get past a validator; worth switching off when nothing is asking.
Skipping lookalike characters is the reverse trade. Removing I, l, 1, O and 0 shrinks the alphabet and costs a bit or so per character, and it is entirely worth it when somebody will read the password off one screen and type it into another. Going straight into a password manager, leave them in and let the manager do the typing.
Frequently asked questions
Is this password sent anywhere?
No, and there is no request that could send it. Everything runs in the page, and the passwords exist only in the tab until you reload. The site has no server component that sees them and no logging that could record them.
How long should a password be?
Sixteen characters from a mixed alphabet is comfortably beyond brute force for anything but a state-level attacker, and twenty is the sensible default if a manager is typing it for you. Below twelve you are relying on the site to hash properly, which is not a bet worth making. Length beats complexity: a long lowercase password is stronger than a short one with symbols in it.
What does the bits figure mean?
Entropy: the base-two logarithm of how many passwords the generator could have produced. Each extra bit doubles the work an attacker faces. Sixty bits resists casual attack, eighty is beyond practical brute force on a fast hash, and past about a hundred and twenty the password stopped being the weak link some time ago.
Why not use a browser's built-in suggestion?
Do, if it suits you. They are generated the same way and stored where you need them. This is for the times you need a password outside a browser form, want a specific shape to satisfy a site's rules, or need twenty at once.
Should I turn off lookalike characters?
Only if you will read it off a screen and type it somewhere else, where I, l, 1, O and 0 cause real trouble. It costs a little entropy, which you can pay back with one more character. Going straight into a password manager, leave them in.
Why does forcing one of each character type reduce strength?
Because it rules out every password that happens to contain no digit, which is a smaller set to search. The loss is under a hundredth of a bit at twenty characters, so it is worth having when a site insists, and the option is there to turn off when it does not.