Skip to main content

Password Generator

Generate cryptographically secure random passwords with configurable length, character types and entropy display.

Reviewed by · Last reviewed

8128

Generating a Password in Five Clicks

  1. Drag the length slider to your target size. The scale runs from 8 up to 128 characters; the entropy readout updates as you move it so you can see the effect immediately.
  2. Toggle the four character-set checkboxes for lowercase (a-z), uppercase (A-Z), digits (0-9), and symbols (!@#$%^&*()_+-=[]{}|;:,.<>?). At least one must stay checked or the output will be empty.
  3. Click "Generate Password". A new password is drawn from the current character pool using crypto.getRandomValues() filling a Uint32Array of the requested length.
  4. Click the Copy icon to drop the result into your clipboard. The page does not redisplay a history of previous passwords, so the value is gone the moment you regenerate.
  5. Paste the password into your password manager first, then into the site that asked for it. Never re-type it by hand; you will lose a character and lock yourself out.

What Happens When You Click Generate

The generator allocates a Uint32Array and hands it to crypto.getRandomValues(), the browser\'s interface to the OS CSPRNG (getrandom(2) on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS). Each 32-bit value is reduced modulo the pool size to pick a character. The resulting modulo bias is negligible at a 94-character pool. The entropy meter shows length * log2(poolSize), so a 16-character all-set password yields about 105 bits. NIST SP 800-63B section 5.1.1 allows any length above 8 characters and removes old composition rules because they produce predictable patterns like "Password1!". Length is the real lever; this tool exposes it up to 128 characters for strict compliance regimes.

Real Scenarios Where You Actually Need This

  • Provisioning a new SaaS account where the browser's built-in suggestion is refused by a misconfigured password policy and you need to hand-pick a length that passes.
  • Rotating API tokens or database service-account passwords after an employee offboarding, where length beats memorability and the value will live only in a secret manager.
  • Generating recovery phrases or master passwords you will type on a mobile keyboard, where you can uncheck symbols to avoid the shift-key dance.
  • Creating many unique Wi-Fi guest passwords before a conference, combining length 12 and a count you generate across multiple runs.
  • Seeding test fixtures with realistic-looking credentials that still pass entropy-based validation in your staging environment.
  • Replacing a default admin password on a freshly flashed home router or smart-home hub where the vendor password is indexed by Shodan.

Ways This Can Still Produce a Weak Result

A generated password is only as strong as the options you pick. If you uncheck every box except lowercase, a 12-character password drops from 78 to 56 bits of entropy, within reach of cloud GPU clusters. The LinkedIn 2012 breach of 6.5 million unsalted SHA-1 hashes was substantially cracked in days on consumer hardware, and the RockYou wordlist (32 million real passwords) means anything shorter than 10 random characters is effectively brute-forceable offline. If you paste into a field that silently truncates (common on legacy apps capped at 20 characters), the stored password is shorter than what you saved in your manager and you will be locked out forever.

The Math Behind Entropy and Why Length Wins

Password entropy is measured in bits and computed as length * log2(poolSize). Adding one character to a 94-character pool adds roughly 6.55 bits. Switching from lowercase-only to all-sets adds log2(94/26) = 1.85 bits per character. Extending a password by 4 characters therefore adds more entropy than adding every symbol class to a short one. NIST SP 800-63B recommends long user-chosen passphrases over short complex strings. EFF long-word Diceware lists compose ~12 bits per dice-rolled word, so a five-word passphrase (~60 bits) approaches a 10-character random password (~66 bits). Entropy is a ceiling: it assumes the adversary has no prior information about your password structure.

Why Not Just Use 1Password or Bitwarden's Generator

Dedicated password managers (1Password, Bitwarden, KeePassXC, Apple Passwords) have the edge for daily use because they auto-save the generated value alongside the site URL, eliminating the copy-paste gap where a password can end up in clipboard history or a Slack draft. This tool wins when you need a password outside the manager\'s UI - writing a Terraform file, filling a form in a session where your vault is not unlocked, or generating a batch for a one-off script. CLI alternatives like openssl rand -base64 24 or pwgen -s 20 10 cover the same ground on a server but do not show entropy in real time. If your threat model includes a malicious browser extension reading DOM content, use an offline tool; if it includes a compromised OS, no in-browser generator can save you.

Frequently Asked Questions

What random source does the generator actually use?

The code allocates a Uint32Array of the requested length and fills it with crypto.getRandomValues(), which the browser wires to the operating system CSPRNG. On modern Linux that is getrandom(2) drawing from the kernel ChaCha20 DRBG, on Windows it is BCryptGenRandom, and on macOS/iOS it is SecRandomCopyBytes. Math.random() is not used anywhere in this tool. These sources are seeded by hardware entropy (RDRAND/RDSEED on x86, interrupt timing on other platforms) and are the same RNGs used for TLS session keys, so the output is suitable for cryptographic use.

Is 12 characters enough or should I use 16 or 20?

NIST SP 800-63B has no hard upper floor beyond 8 characters for memorized secrets, but the modern consensus is 14+ for human-typed passwords and 20+ for anything machine-stored. A 12-character all-sets password has about 78 bits of entropy, which resists offline cracking from a nation-state adversary through at least 2035. If the site stores your password with bcrypt or Argon2, 12 is plenty; if it stores unsalted SHA-1 like LinkedIn did in 2012, even 16 can fall to a determined attacker. Default to 16.

Can I paste a password this tool generates into a field that restricts special characters?

Uncheck the symbol box before generating. The pool falls back to alphanumerics (62 characters), bringing entropy per character down from about 6.55 bits to 5.95 bits, so bump the length by one or two to compensate. Do not manually delete symbols from a generated password - that leaves the remaining characters biased toward whatever the pool would have produced without them.

Does the page remember passwords I have generated?

No. The password is held in a single Preact useState hook. There is no localStorage write, no IndexedDB, no fetch call, and no service worker cache. Closing the tab drops the state. Your browser's form autofill may capture the value if you paste it into a password field, but that happens downstream of this page.

How does this compare to the browser's built-in password suggestion?

Chrome, Safari, and Firefox all suggest passwords when you focus a type="password" field using the same CSPRNG, but with a fixed length and pattern (usually 15-20 characters, mixed case). This tool is useful when the suggestion does not appear, when you need a length outside the default, or when you want to see entropy before accepting it.

What if my password manager's generator already does this?

It almost certainly does, and you should use it first because it auto-saves the result against the site entry. This tool is a fallback for sessions where your vault is locked, a shared kiosk, or throwaway values for testing. The algorithm and entropy guarantees are equivalent; the workflow advantage sits with the vault.

Do I need to enable all four character sets for the password to be strong?

No. Length dominates entropy, so a 20-character lowercase-only password (about 94 bits) beats a 10-character all-sets password (about 65 bits). The old "one upper, one lower, one digit, one symbol" rule was dropped from NIST SP 800-63B because it produces predictable transformations like "Password1!" that dictionaries anticipate. Pick the sets legal on the target site and push length as far as it allows.

Why can two passwords I generate look similar?

At short lengths the character pool is small enough that visual patterns (three vowels in a row, two digits adjacent) show up by chance. True randomness is clumpy; a sequence that looks "too random" is often less random than one with the occasional repeated letter. Regenerating because a password "does not look random enough" introduces human bias and shrinks the real keyspace.

More Security & Privacy