Password Generator

How to use the password generator

Set the length with the slider, tick the character sets you want, and a fresh password appears immediately — every change generates a new one. The defaults are 16 characters drawn from lowercase, uppercase, digits, and symbols, a pool of 89 possible characters at each position, which is a sensible starting point for almost any account. Copy it with the button, or press “New password” if you want a different one. Nothing is generated on a server and nothing is transmitted: the password exists only in the page in front of you, it is never written into the URL, and closing the tab destroys it. That last point is worth taking seriously, because a generator that produces your password anywhere other than your own device has to be trusted with every password it has ever produced.

The randomness comes from your browser’s cryptographic generator, not from the ordinary random function most scripts reach for — that one is a fast, predictable-by-design pseudo-random number generator and has no business guarding an account. Characters are also picked by rejection sampling rather than by taking a random byte modulo the pool size, because the modulo shortcut makes the first few characters of the alphabet measurably more likely to appear. With a pool of 89, a byte from 0 to 255 covers 89 twice fully and then leaves 78 values over, so those first 78 characters would turn up roughly half as often again as the rest. The bias is small, an attacker who knew about it would gain very little, and there is still no reason whatsoever to accept it when discarding the leftover bytes costs nothing.

The strength reading is entropy in bits: how much genuine unpredictability the settings produce. The tool bands it as very weak below 28 bits, weak below 36, fair below 60, strong below 80, and very strong at 80 and above. Alongside it sits a time-to-crack estimate that assumes an offline attacker making 100 billion guesses per second against a fast hash such as MD5 or SHA-1 — a deliberately pessimistic yardstick, not a forecast. Real offline cracking rates vary enormously with the hashing algorithm the site chose: a password stored with bcrypt, scrypt, or Argon2 slows the same hardware down by orders of magnitude, while a password guessed through a rate-limited login form is a completely different problem measured in guesses per minute rather than per second.

None of this matters as much as using a different password everywhere. Most accounts are lost to reuse and phishing rather than to brute force: one breached site hands an attacker a password they will then try on every other service you use, and a phished password is handed over at full strength regardless of how many bits it carries. The practical answer is a password manager — it remembers a unique long password per account so you never have to, which is the only realistic way to make every account independent of every other one. NIST SP 800-63B, revision 4, points the same way: it tells verifiers to screen new passwords against blocklists of known-compromised values and to force a change only when there is evidence of compromise, not on a calendar.

The formula

Strength is measured in bits of entropy — how much unpredictability a randomly generated password actually carries. It depends on exactly two things: how long the password is, and how many characters it could have been drawn from at each position. Nothing else about the string matters, which is why a capital letter on the front and an exclamation mark on the end buy almost nothing.

Because entropy is a logarithm, the two levers behave very differently. Widening the pool adds bits per character in a slow logarithmic way, while adding characters multiplies the whole search space each time. Going from 62 characters to 89 in the pool adds about half a bit per position; adding one character to the length adds a full 6.48 bits at that pool size, more than twelve times as much.

pool size = 26 lowercase + 26 uppercase + 10 digits + 27 symbols = 89
entropy (bits) = length × log₂(pool size)
expected guesses = 2^(bits − 1) — half the space, on average
expected time to crack = 2^(bits − 1) ÷ 100,000,000,000 guesses per second

Worked example with the defaults. All four sets on gives a pool of 26 + 26 + 10 + 27 = 89 characters, and log₂(89) = 6.4757 bits per character. Sixteen characters is therefore 16 × 6.4757 = 103.61 bits, which the tool displays as 104 and rates very strong. For the crack time it halves the space, since an attacker expects to find the answer halfway through on average, so the estimate is 2^102.61 ÷ 100,000,000,000, about 7.7 × 10^19 seconds, or roughly 2 trillion years. Drop to 8 characters and the same arithmetic gives 51.81 bits and about 5 hours — the entire difference is eight characters.

Every crack time on this page assumes one specific attacker: an offline one, working from a stolen password file with no rate limit, at 100,000,000,000 guesses per second against a fast hash of the MD5 or SHA-1 class. State that assumption whenever you quote one of these numbers, because offline cracking rates vary enormously with the algorithm the site used. The same hardware pointed at bcrypt with a sensible work factor, or at scrypt or Argon2, manages a minuscule fraction of that rate, so the real figure for a well-built site is far larger than the one shown. An online attacker guessing through a login form that locks out or throttles is not in the same universe at all. The figure here is a floor to design against, not a forecast of how long anyone would actually take.

This is also why the old advice — eight characters with a capital, a digit, and a symbol — has been retired. Eight characters from the full 89-character pool is only 52 bits, which this tool rates merely fair, and the composition rules that came with it pushed people towards predictable substitutions that guessing software already models. NIST SP 800-63B, revision 4, published in final form in July 2025, states that verifiers SHALL require passwords used as a single factor to be a minimum of 15 characters, SHALL NOT impose composition rules requiring mixtures of character types, and SHALL NOT require subscribers to change passwords periodically — only when there is evidence of compromise. It also requires new passwords to be screened against a blocklist of commonly used, expected, or compromised values. A generated password satisfies all of that by construction, because it was never a human choice in the first place.

Frequently asked questions