A password from your browser's own randomness
Generated with crypto.getRandomValues, drawn without bias, and never sent anywhere. The strength figure is counted from the actual number of passwords this generator could have produced — including the cost of the options you turn on.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
Why "require one of each" makes a password weaker, not stronger
It reduces the number of passwords that can be produced. Before the requirement, every string of the chosen length over the chosen alphabet is possible; afterwards, all the ones missing a category have been removed. Fewer possibilities is less entropy, always.
The effect is small at twenty characters and large at six — which is unfortunate, because six is where people are most likely to leave the box ticked. This page shows the cost in bits whenever it is not negligible, rather than the usual approach of displaying a bigger number because more boxes are checked.
There is a second, subtler problem the option usually brings with it. The common way to implement it is to place one character from each category and shuffle the rest, and that does not produce a uniformly random password satisfying the constraint — it skews toward strings with exactly one character from each of the rarer categories. Here the generator draws uniformly and simply starts again if a category is missing, which gives the genuinely uniform distribution that the entropy figure describes.
The honest advice: leave it off and add two characters instead. You will end up with more entropy and fewer rules.
Where the randomness comes from
crypto.getRandomValues, your browser's cryptographically secure random number generator, seeded by the operating system. Never Math.random, which is fast, predictable from its own output, and completely unsuitable — the test suite checks the source files for it.
Turning random bytes into a random character needs one more piece of care. The obvious method — take a 32-bit number and use the remainder after dividing by the alphabet size — is measurably biased toward the earlier characters whenever the alphabet size does not divide evenly into 2³². The bias is small per character and compounds across a password. This generator throws away and redraws the values that would land in the short final block, which removes it entirely.
Why there is no "time to crack" here
Because it would be a number about an assumption rather than about your password. How long a password survives depends on how the site you used it on stored it, what hardware is doing the guessing, and whether anybody is guessing at all rather than simply reading it out of a breach. A tool in your browser knows none of those things.
What it can tell you honestly is the entropy — how many equally likely possibilities the password was drawn from. Above about 80 bits, no guessing attack against a properly stored password is feasible with anything that exists, and the limiting factor stops being the password. That is the useful thing to know.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
How long is long enough
For anything a password manager will remember on your behalf: 20 characters or more, with whatever categories you like. There is no reason to economise on length you will never type.
For something you have to type regularly — a device login, a disk password, the password manager's own master password — a passphrase is the better instrument. Six or seven random words are far easier to type accurately and to remember than sixteen random characters, and can carry more entropy.
Below about 40 bits, an attacker who has your stored password and can guess offline will get it. Between 40 and 60 it depends heavily on how it was stored. Past 80 there is no realistic attack, and past 128 the password has long stopped being the weakest thing in the chain.
The rules that make passwords worse
Mandatory symbols, forced expiry every 90 days, and "must contain a number" all push people toward the same handful of predictable shapes — a capital at the front, a digit and an exclamation mark at the end. NIST dropped the composition and expiry requirements from its own guidance in 2017 for exactly that reason. Length and randomness are what matter.
Related
A passphrase for anything you have to type, or the secure random generator for API keys and tokens where readability does not matter.
Questions people actually ask
Where does the randomness come from?
crypto.getRandomValues, your browser's cryptographically secure generator, seeded by the operating system. Never Math.random — the test suite reads the source files and fails if it appears in either module.
Why does the entropy go down when I require one of each category?
Because the requirement removes possibilities. Every password missing a category is no longer available, so there are fewer to choose from, and fewer possibilities is less entropy. The effect is tiny at twenty characters and significant at six. The page shows the cost in bits whenever it is not negligible.
Is "one of each" implemented the usual way?
No. The usual way — place one character from each category and shuffle — does not produce a uniformly random password satisfying the constraint; it skews toward strings with exactly one character from the rarer categories. Here the generator draws uniformly and starts again if a category is missing, which gives the distribution the entropy figure actually describes.
Why is there no "time to crack"?
Because it would be a number about an assumption, not about your password. How long it survives depends on how the site stored it, what hardware is guessing, and whether anyone is guessing at all rather than reading it from a breach. Entropy is the honest measure: above roughly 80 bits there is no feasible guessing attack, and the password stops being the weak link.
Should I use symbols?
They help a little and cost a lot of typing. Going from letters and digits to letters, digits and symbols adds about 0.5 bits per character; adding two more characters adds about 12. If the password lives in a password manager, length is free and symbols are not.
Is the password sent anywhere?
No. It is generated in your browser and stays there. Nothing on this page contacts a server, and the shared engine refuses to emit any analytics event containing a value of this kind at all.