A password generator creates a random string of characters from a pool you choose — uppercase letters, lowercase letters, digits, and symbols — so the result is unique and far harder to guess than anything a person would make up by hand. Strength is measured in bits of entropy, calculated as length multiplied by log2 of the pool size; with all four character types enabled, the pool holds 86 distinct characters, so each character adds roughly 6.4 bits. That means a 16-character password from the full pool carries about 103 bits of entropy, while a 12-character one carries about 77 bits — a useful rule of thumb is that anything under 60 bits is weak, 60 to 100 bits is fair, and 100+ bits is strong against offline brute-force attacks. A trustworthy generator pulls its randomness from a cryptographically secure source rather than the predictable Math.random function, applies it uniformly without modulo bias, and runs entirely in your browser so nothing is ever transmitted to a server.
People reach for a password generator whenever they need to create an account, rotate a credential, or replace a weak reused string. The tool's job is to remove the human element — the predictable patterns, the birthdays, the keyboard walks — and substitute genuine randomness drawn from the device. Using a strong random password generator is now standard practice for both individuals and developers building sign-up flows, because the alternative — memorable words chosen by a person — is exactly the kind of input attackers have spent decades learning to crack.
How to Generate a Strong Password
The whole process takes a few clicks and does not require an account, a sign-up, or an upload. The tool you use should let you tune length and character sets, show you the resulting entropy, and hand you the finished string with one click.
- Open the Password Generator in your browser tab.
- Set the length with the slider or number box. Longer is stronger; 16 characters is a sensible default for most accounts, and 20 or more is worth using for anything high-value.
- Toggle which character types to include. Uppercase, lowercase, digits, and symbols all add to the pool; if you do not need a password to be typed by hand often, leave them all on.
- Optionally exclude ambiguous characters like 0, O, 1, and l so the string is easier to read on paper or in a phone call.
- Read the strength and entropy estimate the tool reports — confirm it is in the "strong" range (100+ bits) before you commit.
- Click Copy to grab the password to your clipboard, or Generate to roll a fresh one until you get a value you like.
- Paste the result straight into the account form or your password manager. Close the tab once you are done; nothing is stored.
What Changes When You Add Length or Character Types
Two knobs move entropy: length and pool size. Pool size is the number of distinct characters the generator can pick from, and it grows every time you enable a new character type. The relationship between pool size and bits-per-character follows a log2 curve:
| Character types enabled | Pool size | Bits per character |
|---|---|---|
| Lowercase only | 26 | ~4.7 bits |
| Lowercase + uppercase | 52 | ~5.7 bits |
| Lowercase + uppercase + digits | 62 | ~6.0 bits |
| Lowercase + uppercase + digits + symbols | 86 | ~6.4 bits |
The "bits per character" column is just log2 of the pool size — it tells you how much uncertainty each position in the password adds. Adding symbols to a 16-character password moves you from about 95 bits to about 103 bits; useful, but modest. Doubling the length from 16 to 32 characters with the same pool takes you from roughly 103 bits to about 205 bits — a much bigger jump. Length is the single most powerful lever, which is why NIST and OWASP now favor long strings or passphrases over forced complexity rules that swap character sets without adding characters.
Here is the math worked out for one common case: with all four character types enabled, the pool is 86 characters, so log2(86) ≈ 6.426. Multiply that by a length of 16 and you get 16 × 6.426 ≈ 103 bits of entropy. The same formula applied to a 12-character password from the same pool lands at about 77 bits — fair, not strong. What matters is the size of the pool the generator can choose from, not how exotic any individual symbol looks.
How Strength Tiers Map to Entropy
Once you know the bits, the rest is interpretation. The thresholds below are a practical rule of thumb for measuring how resistant a password is to offline brute-force attack — a setting where an attacker can test guesses at full hardware speed against a stolen hash database:
| Entropy (bits) | Tier | What it means |
|---|---|---|
| Under 60 | Weak | Crackable in hours or days on consumer GPUs; do not use for real accounts. |
| 60 to 100 | Fair | Resists casual attack but vulnerable to a motivated, well-resourced adversary. |
| 100 and above | Strong | Holds up against realistic offline brute-force scenarios for the foreseeable future. |
A 12-character password from the full 86-character pool lands at about 77 bits — fair, not strong. A 16-character password from the same pool reaches about 103 bits — strong. This is exactly why the tool's recommended default sits at 16 or above.
Where the Randomness Actually Comes From
Two pieces have to be right for a generator to produce a secure password: the source of randomness, and the way random numbers get mapped onto characters. Get either one wrong and the output is weaker than its length suggests.
The source matters because JavaScript's built-in Math.random function is fast but predictable. Given enough previous outputs, an attacker can reconstruct its internal state and predict future values. That is fine for a video game; it is unacceptable for a secret. A cryptographically secure RNG — specifically the browser's crypto.getRandomValues() API — is designed so its output cannot be distinguished from true randomness, even by an adversary who can see every value it has ever produced. A trustworthy password generator always uses the CSPRNG, not Math.random.
The mapping matters because of a subtle issue called modulo bias. If you take a 32-bit random integer and reduce it modulo the pool size, some characters in the pool will appear slightly more often than others whenever 2^32 does not divide cleanly by the pool. The bias is small — a fraction of a percent — but it does shrink true entropy and makes output more predictable. The fix is rejection sampling: throw away any random value that would land in the biased remainder band and redraw. Done correctly, every character in the chosen set appears with exactly equal probability. The generator also guarantees at least one character from each type you selected, then shuffles the whole result with the Fisher–Yates algorithm so the guaranteed characters are not pinned to predictable positions.
Because generation happens locally in the browser, the password is never transmitted over the network, written to a server log, or stored anywhere. It exists only in your browser tab until you copy it, and closing the tab discards it. That local-only design is what makes an online generator private: the randomness comes from your own device through crypto.getRandomValues, and the finished string never leaves it.
Modern Guidance: Length Over Forced Complexity
Older advice insisted on uppercase plus lowercase plus a digit plus a symbol — a set of rules that produced passwords people could barely type and attackers could still guess. OWASP's Authentication Cheat Sheet and NIST Special Publication 800-63B now point the other way: long, random, unique strings beat short, complex ones, and the priority is to screen candidates against known breached password lists. A generator's job is to produce those long, random, unique strings reliably; your password manager's job is to remember them so you do not have to.
Two practical rules cover most situations. First, use a unique generator-produced password for every account so a breach on one site does not leak the others — the password strength checker is a useful companion tool for auditing passwords you already hold. Second, prefer 16 or more characters for accounts that matter, and lean on a password manager rather than memory for everything else. The combination — long, random, unique, manager-stored — is what modern guidance actually asks for, and a good generator is the first half of that workflow.
Related reading: Generate a SHA256 Hash from a String in C# and Verify.
Related reading: Password Strength Algorithm: Rules Behind the Score.