How to Generate Strong Passwords You Can Actually Trust

A password's strength is measured in entropy - roughly, how many attempts an attacker would need to guess it by brute force. Entropy grows with two things: the length of the password and the size of the character set each position is drawn from. A 20-character password built from uppercase, lowercase, digits, and symbols has vastly more possible combinations than a 20-character password of lowercase letters only, and both crush an 8-character password no matter how it is mixed.

This is why security guidance has shifted over the last decade: complexity rules like "must contain a symbol" matter far less than raw length. A long, fully random password beats a short, rule-satisfying one every time, because entropy scales exponentially with each extra character.

Tr0ub4dor!  (11 characters, mixed case + digit + symbol)

correct-horse-battery-staple-42  (32 characters, lower entropy per character but far higher total entropy)

A password is only as unpredictable as the process that created it. If a human picks the characters, patterns creep in - favorite words, keyboard walks, dates, or a shifted version of an old password. Even software can get this wrong: Math.random() in JavaScript is a fast, general-purpose pseudo-random number generator, not a cryptographic one. It is seeded and generated in ways that are not designed to resist prediction, so it should never be the source of anything meant to protect an account.

The correct tool for the job is crypto.getRandomValues, a browser API built specifically for cryptographic use. It draws from the operating system's secure random source, and a well-built generator layers rejection sampling on top of it so that every allowed character has an exactly equal chance of appearing - no bias toward the start or end of the character set.

Generating a password comes down to three decisions: how long it should be, which character sets to draw from, and whether to exclude characters that are easy to misread. The Password Generator exposes all three directly, then fills each position with a cryptographically random selection from the resulting pool and shows a live entropy and strength estimate as you adjust the settings.

• Length - the single biggest lever for entropy. Short PINs are useful for things like device unlock codes; 16 or more characters is the right baseline for anything protecting an account or secret.
• Character sets - uppercase, lowercase, digits, and symbols can be toggled independently, so you can match a site's specific requirements or maximize the pool size when there are no restrictions.
• Ambiguous-character exclusion - characters like 0/O and 1/l/I look alike in many fonts. Excluding them trades a small amount of entropy for a password that is easier to type or read aloud correctly.

1. Open the Password Generator and set the length - 16 or more characters is a solid default for most accounts.
2. Enable the character sets the target site allows: uppercase, lowercase, digits, and symbols. Leave every set on unless a site restricts them.
3. If the password will be typed or read aloud (a WiFi passphrase shared verbally, for example), turn on ambiguous-character exclusion.
4. Check the live strength estimate, then generate. If you need several at once, use bulk generation to provision multiple accounts in one pass.
5. Copy the password directly into your password manager - not into a note, a chat message, or a shared document.

• Creating a unique password for a brand-new account instead of reusing an existing one.
• Rotating credentials after a service discloses a breach or you suspect reuse elsewhere.
• Generating API keys, database passwords, and other service secrets during setup.
• Producing a WiFi passphrase that avoids confusing look-alike characters for guests typing it on a phone.
• Provisioning passwords for many accounts at once with bulk generation, then distributing them through a password manager.

Reusing the same password across sites

A single leaked password gets tried everywhere. Credential-stuffing attacks exist specifically to exploit reuse, so every account - especially email, banking, and anything tied to recovery flows - needs its own independently generated password.

Starting from a memorable pattern

Capitalizing the first letter, appending ! or a birth year, or substituting 4 for A are all patterns attackers already model for. A password derived from a habit is not meaningfully more secure than the habit itself. Fully random generation avoids this entirely.

Storing generated passwords in plaintext

A strong password loses its value the moment it sits in an unencrypted note, spreadsheet, or chat thread. Copy it directly into a reputable password manager, which is designed to store and autofill secrets without exposing them elsewhere.

Chasing complexity rules instead of length

Satisfying "one uppercase, one digit, one symbol" with the shortest possible password is a common trap. When a site allows it, prefer a longer password over one that merely checks every complexity box.

• Default to 16+ characters with every character set enabled unless a site restricts symbols or length.
• Only exclude ambiguous characters when a human genuinely needs to read or type the password.
• Generate a fresh password per account - never adapt or reuse one, even with small changes.
• Pair generated passwords with a password manager and, where available, multi-factor authentication.
• For related identifiers rather than secrets - like public API keys or record IDs - a UUID Generator or Nano ID Generator is a better fit than a password.