Random Password Generator

A password worth using

A password is only as good as the process that produced it. People make bad ones predictably — a word, a capital at the front, a digit and a punctuation mark at the end — and that shape is exactly what cracking tools try first. A secure password is not a clever one; it is one drawn at random, with no pattern to attack and nothing to guess but the characters themselves. That is all this generator does, from the pool of characters you choose.

What the defaults are, and why

• Twenty characters. Length buys more than any other choice: each extra character multiplies the search space by the size of the pool. Twenty from the full set is around 131 bits of entropy, which is past the point where guessing is the attacker's best option.
• All four character classes on. Lower case, upper case, numbers and symbols give a pool of 88 characters rather than the 26 a single class would.
• Look-alike characters left in. Excluding I l 1 O 0 and friends makes a password easier to read off a screen, but it shrinks the pool, so it is a choice to make deliberately rather than a default.

How the randomness works

Characters come from the Web Crypto API's getRandomValues, which is the operating system's cryptographic random source — not Math.random, which is seeded from observable state and is not designed to be unpredictable. If the browser has no Web Crypto support the tool refuses to generate anything rather than quietly producing a weak password.

Two details matter beyond the source. Indexes into the character pool are drawn with rejection sampling instead of a modulo, because 2³² is not a multiple of most pool sizes and the remainder would make the first few characters of the pool marginally more likely. And the password is shuffled after the one-per-class characters are placed, so a symbol never lands at a predictable position.

Passwords you type, and passphrases

A random string is the right answer for the few hundred accounts that live in a password manager, because nothing ever types them by hand. For the handful you type from memory — the device login, the manager's own master password — a passphrase of five or six randomly chosen words is easier to type on a phone keyboard and easier to hold in your head at comparable strength. This tool generates characters rather than words, so pick those few with dice or a wordlist and keep a strong generated password for everything else.

What happens to the password

Nothing. Generation happens entirely in the page: no password is sent to this site's server, and none is written to localStorage, sessionStorage or a cookie. Reloading or closing the tab discards it, which is deliberate — a generator that remembered its output would be a list of live credentials sitting in the browser profile, and browser storage has no defence against a script that gets onto the page — there is more on that in the notes on cookies and local storage. Paste it into a password manager, and use a different one for every account.

Entropy, and why it is the number that matters

The strength bar above quotes a figure in bits. It is worth understanding, because it is the only honest way to compare one password with another — everything else people say about password strength is a proxy for it, and usually a bad one.

It measures the process, not the password

Entropy is a property of how a password was produced, not of the characters that came out. Take Xk7$mQ2v generated here, and the identical string typed by someone who thought it looked random. They are the same eight characters. The first was drawn from 88⁸ equally likely possibilities; the second came from the much smaller, much lumpier set of strings a person invents when asked to be random — people favour the home row, alternate hands, put the digit near the end and the capital at the front.

An attacker does not guess strings at random; they model the process and start with what it makes likely. That is why a strength meter that inspects the characters you typed can only ever estimate: it can spot a dictionary word or a keyboard walk, but it cannot see where the password came from. This tool can state the figure exactly, because it knows the process — it is the one that ran it.

Where the number comes from

A password of L characters drawn from a pool of N has N^L equally likely forms. Those numbers get unwieldy fast, so they are quoted as base-2 logarithms — bits — which turns multiplication into addition: bits = L × log₂(N).

With all four character classes switched on, the pool here is 88 characters, and log₂(88) is about 6.46 bits per character. Twenty characters is therefore just over 129 bits. The useful intuition is that every extra bit doubles the number of guessesrequired, so ten bits is roughly a thousandfold more work and twenty bits is a millionfold.

The same arithmetic covers passphrases, which is what makes them comparable: six words picked at random from a 7,776-word list is 6 × log₂(7776) ≈ 77 bits — about the same as twelve characters from the full pool here, and considerably easier to type.

What a given number of bits is worth

Bits only become time once you fix a guessing rate. Two are shown below: a trillion guesses a second, which is the order of magnitude a rented rack of GPUs reaches against a password stored with a fast hash such as unsalted MD5 or SHA-1; and a hundred thousand a second, which is roughly what the same hardware manages against bcrypt or Argon2 at sensible settings.

The bottom row is this tool's default. The jump between the two columns is the whole argument for slow password hashing: the same password, stored two different ways, differs by seven orders of magnitude in how long it survives.

You do not get to pick the attacker's speed

Three regimes matter, and they are far apart. Against a live login form, rate limits and lockouts hold an attacker to a few hundred guesses an hour, so even 40 bits never falls. Against a stolen database, the rate is set entirely by how the site stored the password — the two columns above. And if the site stored passwords in plain text, no amount of entropy helps at all.

The point is that you never find out which regime you are in until the breach notice arrives, and by then the hashes have been public for months. Choosing a long password for an account you consider trivial is not paranoia; it is the only part of that arrangement you control.

Length beats complexity

Both levers work, but not equally. Twenty lower-case characters is 94 bits. Turning on the other three classes takes the same twenty characters to 129 bits — a real gain of 35 bits. But twenty-eight lower-case characters, with no symbols or digits at all, is 132 bits: eight more characters of one class beats adding three whole classes. Length multiplies; the pool size only shifts the per-character rate.

This is why composition rules — must contain an upper case letter, a digit and a symbol — buy so little. They add a bit or two of theoretical pool while pushing people towards the transformations every cracking wordlist already tries: a to @, s to $, a capital at the front and a ! at the end. NIST dropped composition rules from its digital identity guidelines (SP 800-63B) for that reason, and now asks for length and a check against known-breached passwords instead.

What entropy does not protect you from

Entropy is a defence against guessing, and against nothing else. A 129-bit password is phished exactly as easily as hunter2, read just as cleanly by a keylogger, and handed over just as completely by a site that stored it in plain text. Nor does it survive reuse: the strongest password in the world is worth its full 129 bits on the first site and nothing on the second, because the weakest site you used it on decides when it leaks.

Which is the real argument for a password manager. Generate a long random password per account, never type any of them, and the number above becomes the whole of the guessing problem rather than one factor among several.