Generate passwords from the Web Crypto generator by rejection sampling, with the entropy stated exactly from the alphabet, the cost of every rule computed, and crack times against four named attacker models
Initializing in your browser…
An upper bound on how strong a password is, from the patterns that actually make one guessable, with the model and its limits stated in full.
Generate realistic fake data for testing and development. Create names, usernames, emails, addresses, phone numbers, and more. Export to JSON or CSV format
Build a Subresource Integrity attribute, with more than one hash if you want, and check an existing one against the file it is meant to pin.
A database root password for a runbook: 24 characters, one of every class because the policy demands it, and no character anyone can misread when they type it from the screen.
Settings
Length 24, A-Z + a-z + 0-9 + symbols, contain one of each, leave out look-alike characters
What the page reports
efbk(KEpQDXtY\Ct+e!:#3kM Alphabet 73 characters (94 less the 21 look-alikes) Per character 6.190 bits Length 24 Total 147.9 bits, more than enough Requiring A-Z, a-z, 0-9 and symbols accepts 63.4 percent of all passwords of this length, which costs 0.66 bits: 148.6 becomes 147.9. Online, rate limited 10^35 years 1e2 guesses/s Offline, bcrypt at cost 12 10^32 years 2e4 guesses/s Offline, PBKDF2 at 600,000 10^33 years 8e3 guesses/s Offline, a single fast hash 10^26 years 1e11 guesses/s Only 3 of the 10 characters of 0-9 are left (347). A class that small makes "contain one of each" expensive, because most drawn passwords will not have one. Draw 3,000 and test (one run): chi-square 68.7 against a 0.01 critical value of 102.8 for 72 degrees of freedom, so the raw draw is as flat as chance allows class share of the alphabet share once the rule is on A-Z 24.7% 24.0% a-z 31.5% 30.5% 0-9 4.1% 6.5% Symbols 39.7% 39.0%
Four numbers here are the point. 6.190 bits a character rather than 6.555 is what the look-alike exclusion costs, and it is worth knowing before choosing a length rather than after. 0.66 bits is what the "one of each" rule costs, computed by inclusion and exclusion over the four classes rather than assumed to be free: the rule removes passwords from the space, so it makes the password very slightly weaker, not stronger, and the generator redraws whole passwords rather than placing one of each and shuffling, so what comes out is still uniform over the ones that qualify. And 147.9 is the entropy of the process, which is the same for every password these settings produce; a strength meter that infers the alphabet from the characters that came up would give a different, lower number about half the time at short lengths, and would call Password123! a 79-bit password. The fourth is the one in the table: with only three digits surviving the look-alike exclusion, keeping just the passwords that contain a digit lifts the digit share from 4.1 percent of the characters to 6.5, and the page reports that rather than running a chi-square over it and calling the generator broken. The joint distribution over whole passwords is still exactly uniform over the ones that qualify, which is what the 147.9 counts; it is the per-character marginal that moves, and it moves because the rule says it should.
A generated password is worth exactly its length times the logarithm of the alphabet it came from, and that number is knowable rather than estimable. Set the length and the character classes and the page states the figure, what any rule you add costs, how long it holds against four named attackers, and it will draw three thousand passwords and test the distribution if you ask it to.
The first is that every character has to be equally likely. A random byte reduced modulo an alphabet size that is not a power of two favours the first few characters, so every draw here is rejection sampled instead. On a 94-character alphabet drawn from 32 random bits that particular bias is about one part in fifty million and no sample of any practical size could detect it; it costs nothing to do properly, so it is done properly. The bias that IS large enough to see is a duplicate: an alphabet string with a character in it twice picks that character twice as often, and adding characters that a class already contains is exactly how that happens. The alphabet is deduplicated before anything is drawn, and the page says which characters were counted once and why it matters.
The second is that the entropy is known rather than inferred. For a generated password it is the length times the log of the alphabet, full stop. Reading the alphabet back off the characters that happen to be in the output gives a lower number whenever a class did not come up, which for an eight-character password from all four classes happens about half the time. It also gives a wildly optimistic number for a password a person chose: a character-class model calls Password123! a 79-bit password, and a cracking dictionary finds it in under a second. The figure here is the entropy of the process, and it is the same for every password the same settings produce.
The third is the "must contain one of each" rule that so many sites demand. It costs entropy, because it removes passwords from the space, and the cost is computable exactly by inclusion and exclusion: requiring all four classes in an eight-character password accepts 46.1 percent of them and costs 1.12 bits, at twelve characters 70.0 percent and 0.51 bits, at sixteen 82.3 percent and 0.28 bits. The page prints those numbers. It matters how the rule is enforced as well as what it costs: this draws a whole password and starts again if it does not qualify, so what comes out is still uniform over the passwords that do. Placing one character of each class and shuffling is not uniform, and the entropy figure would then be the entropy of nothing in particular.
The alphabet is the 94 printable ASCII characters that are not a space, split into four classes that do not overlap. A separate shell-safe symbol set of fourteen is offered for a password that has to survive a shell, a URL, a CSV or a SQL string. The look-alike exclusion covers more than the usual five: in a monospace font 5 and S, 8 and B, 2 and Z, and 6 and G are as easy to misread as l and 1, so the groups are listed on the page rather than promised, and turning it on takes the 94-character alphabet to 73, which is 6.190 bits a character rather than 6.555.
A crack time without a rate is meaningless, so four rates are given with what each one means: a rate-limited login at a hundred guesses a second, a stolen database hashed with bcrypt at cost 12 or with PBKDF2 at the 600,000 iterations OWASP currently recommends, and a stolen database hashed with a single round of SHA-256, which is what a breach usually turns out to be. The arithmetic is done in logarithms, so a 128-character password at 839 bits produces a readable figure rather than Infinity.
Nothing is stored and nothing is transmitted. The settings go into the share link so a colleague can reproduce them; the passwords and the two free-text character fields never do.
Sixteen characters of the full set is 104.9 bits, which is past the point where an offline attack on a fast hash is worth anyone's time.
The shell-safe symbol set leaves out everything that needs escaping, at a cost of 0.3 bits a character that a couple of extra characters more than covers.
Turn on the look-alike exclusion and read the list first: it removes 21 characters, which the page prices at 6.190 bits each instead of 6.555.
"Contain one of each" guarantees the digit and the symbol the form insists on, and the page tells you what that guarantee costs.
The distribution check draws three thousand passwords and tests the character counts against a uniform distribution, with the critical value shown.
Because it should not. The entropy of a generated password is a property of how it was made, not of the characters that came out. Sixteen characters drawn uniformly from 94 is 104.9 bits every time, whether or not this particular one happens to contain a digit.
No, it makes it slightly weaker, and the page says by how much. The rule removes passwords from the space, so there are fewer to guess: at eight characters requiring all four classes costs 1.12 bits, at sixteen it costs 0.28. It is worth doing when a site demands it and not otherwise. One more character buys back far more than the rule costs.
That the alphabet is not lopsided, which is the mistake that actually happens: a duplicate character, or a modulo over too small a range. It cannot tell a cryptographic generator from a predictable one, and no distribution test can. Math.random passes this test comfortably and is still guessable from a handful of outputs, which is why the page says where its randomness comes from as well as showing the statistic.
The one that matches how the other end stores your password, which you usually do not know. The honest reading is the fast-hash row, because a breach usually turns out to have been a single round of SHA-256 or worse. That row is why 80 bits is the number to aim for rather than 60.
The groups are listed on the page so you can see exactly what goes. The usual five, I l 1 O 0, leaves 5 and S, 8 and B, 2 and Z, and 6 and G, which are just as easy to misread in most monospace fonts, so those are in the list too, along with the pipe, 9 g q, U V and the backtick against the apostrophe.
Not here. A Diceware passphrase needs a published word list of 7,776 entries, which is a large thing to load into a page for one feature, so it is not offered rather than being offered badly. At 12.9 bits a word, six words is 77.5 bits, which is roughly what twelve characters of the full set gives you.
No. Generation happens in the page, nothing is kept between visits, and the password never reaches the address bar or the share link. The length and the character classes do, so a colleague can reproduce the settings, but the free-text "also allow" and "never use" fields stay here too.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.