Random Password Generator

A random password generator creates passwords by drawing each character from a cryptographically secure random source rather than from a word list, dictionary, or human-inspired pattern. It is used by developers creating new service accounts, by security teams provisioning temporary credentials, by IT administrators setting Wi-Fi PSKs on enterprise hardware, by privacy-conscious individuals opening new accounts at banks and email providers, by database administrators rotating root passwords, by DevOps engineers generating one-time keys for CI/CD pipelines, by penetration testers producing throwaway accounts during engagements, and by anyone who needs a password that resists brute-force, dictionary, and pattern-based attacks. The generator runs entirely in your browser using the W3C WebCrypto API, so the password never touches a server, never appears in a log, and never leaves your device.

Why a Random Password Generator Matters

Humans are terrible at picking random strings. The password Tr0ub4dor&3 looks strong, twenty characters, mixed case, digits, symbols, but it was built from a memorable word with a few substitutions, and cracking software knows this. Sophisticated password crackers (John the Ripper, hashcat, the rockyou.txt variations) run mangling rules that convert every word in a million-word dictionary into a billion candidate passwords, and they crack a typical "clever" password in minutes on a single GPU. A truly random password of the same length drawn from a 92-character pool has no such shortcut. The expected brute-force time grows exponentially with entropy, and at 80 bits of entropy (a 12-character all-classes password) the brute-force cost exceeds the entire global Bitcoin hashrate sustained for the age of the universe. The job of a random password generator is to produce secrets whose entropy comes from mathematics rather than from human creativity.

How to Use the Random Password Generator

1. Move the length slider to your desired password length, between 6 and 128 characters. The default of 16 characters is appropriate for most consumer accounts; enterprise and root credentials should be 20 or longer.
2. Enable the character classes you want to include: uppercase A-Z, lowercase a-z, digits 0 to 9, and symbols. At least one class must be enabled, the button is disabled otherwise.
3. Optionally toggle avoid ambiguous characters to remove 0, O, o, I, l, and 1 from the pool. This makes passwords easier to read aloud and type on mobile devices at the cost of a few bits of entropy.
4. Click Generate 5 passwords. Five suggestions are produced, each one independently drawn from the cryptographically secure random source.
5. Click the Copy button next to any suggestion to copy it to your clipboard. The "Copied!" indicator confirms the copy for one and a half seconds.
6. Adjust the length or classes and click Generate again to roll a fresh batch. Re-using the same length and classes produces a new random set on each click.

The Formula

The entropy of a password is the number of bits a brute-force attacker must recover, on average, to guess it. For a password of length L drawn uniformly at random from a pool of N distinct characters, the entropy in bits is:

H = L × log₂(N)

With all four character classes enabled (uppercase 26, lowercase 26, digits 10, symbols 30), the pool size is 92. A 16-character password therefore has entropy 16 × log₂(92) ≈ 16 × 6.52 ≈ 104.3 bits. The strength meter reports Weak below 40 bits, Fair below 60, Good below 80, Strong below 100, and Very strong at 100 bits or more. Disabling the symbols class drops the pool to 62 and the entropy per character from 6.52 to 5.95 bits; a 16-character password then has about 95 bits, still firmly in the Strong band but worth knowing about if you are designing a security policy.

Enabling more character classes is the cheapest entropy improvement. Doubling the pool size adds one bit per character. To put 104 bits in perspective, that is about 32 orders of magnitude more combinations than the entire Bitcoin network has hashes per second, year after year. The attacker who guesses one such password per nanosecond with a million parallel machines would expect to wait longer than the age of the universe.

Character Classes and the Avoid-Ambiguous Toggle

The four character classes are standard in NIST SP 800-63B and the legacy composition rules that many authentication systems still enforce:

• Uppercase (A-Z). Adds 26 characters. Almost universally accepted.
• Lowercase (a-z). Adds 26 characters. Almost universally accepted.
• Digits (0 to 9). Adds 10 characters. Universally accepted.
• Symbols (!@#$%^&*()_+-=[]{};:,.<>?/). Adds 30 carefully chosen punctuation characters. Some systems reject particular symbols (especially the apostrophe, backslash, and double quote), so the symbol set is intentionally limited to characters that work in most SQL, JSON, and shell contexts.

The avoid ambiguous characters toggle removes 0 O o I l 1 from the pool. These six characters are responsible for the majority of "did I type that correctly?" confusion when passwords are read aloud, written on paper, or transcribed by hand. If you regularly need to type a generated password from a printed recovery sheet, enable this toggle. The entropy cost is small: with all four classes enabled, ambiguity-free mode drops the pool from 92 to 86, losing about 0.10 bits per character.

NIST SP 800-63B explicitly retired the old policy of requiring at least one character from each class. Modern guidance focuses on length and entropy, not composition. The toggle here lets you choose the trade-off: follow the new NIST guidance (any length, any mix) or accommodate legacy systems that still want a symbol.

Why Client-Side Matters (POPIA, GDPR, and the Server-Stored Password Problem)

Every online password generator solves a problem and creates a worse one. The problem it solves: humans are bad at randomness. The problem it creates: you have to trust the server to discard the generated password. Even with HTTPS, server logs, application logs, CDN logs, and observability platforms may capture the value. The password may sit in a database row marked "ephemeral" for a few microseconds longer than expected. A misconfigured log rotation may keep it for weeks. A subpoena to the server operator may force disclosure.

A pure client-side generator eliminates this entire category of risk. The page loads, the JavaScript runs in your browser, the random bytes are drawn from crypto.getRandomValues, and the resulting password is rendered to your screen. Nothing is sent over the network. There is no fetch() call, no analytics endpoint, no telemetry. There is no localStorage write, no sessionStorage write, no IndexedDB write. The password exists in the React component's state at the moment it is generated; closing the page or refreshing the browser destroys it. The only place the password goes is wherever you paste it (your password manager, a credential file, a one-time note).

For organisations bound by POPIA (the South African Protection of Personal Information Act), GDPR, CCPA, HIPAA, or SOC 2, the data-processor question is the hard one. Under POPIA, a "responsible party" must justify any transfer of personal information to an "operator", an online password generator is exactly such an operator. Running the generator client-side removes the data-subject and operator analysis entirely. The generator does not process personal information because it never receives any. Auditors like this answer.

Cryptographic Randomness, How crypto.getRandomValues Works

Browsers expose the WebCrypto API at window.crypto. The crypto.getRandomValues(typedArray) method fills a typed array with cryptographically secure random bytes. Under the hood, the browser delegates to the operating system's CSPRNG: Linux's getrandom(2) syscalls after kernel 5.10, macOS's SecurityRandom (backed by the kernel's CPRNG), Windows' BCryptGenRandom. These CSPRNGs are seeded from hardware entropy sources (CPU timing jitter, disk seek jitter, network packet timing, dedicated hardware RNGs on modern CPUs via RDRAND/RDSEED) and are continuously re-seeded. The output passes the NIST SP 800-22 statistical test suite and is suitable for key generation, nonces, and authentication tokens.

A naive implementation of a password generator is pool[Math.floor(Math.random() * pool.length)]. This is wrong for two reasons. First, Math.random() is not cryptographically secure, given a few outputs, an attacker can recover the internal state and predict the next outputs. Second, the modulo-mapping byte % pool.length is biased when the pool size does not divide 256 evenly; for a pool of size 30, the first 16 pool characters get a 1/256 chance and the remaining 14 get a 0/256 chance, so the distribution is slightly lopsided. This generator uses crypto.getRandomValues and rejection sampling: draw a byte, if it falls in the biased range (the slack at the top of the 256-element space), reject it and draw again. The expected number of draws per character is at most 256/(256 − slack) which is bounded by 2 for any reasonable pool size.

Worked Examples

Example 1, Consumer email account. Alice wants a strong password for a new Gmail account. She picks length 18 with all four classes enabled. Pool size 92, entropy 18 × 6.52 ≈ 117 bits. The generator returns five 18-character strings. Alice pastes the first one into Gmail and into her password manager. The remaining four are discarded.

Example 2, Database root password. A DBA needs a new root password for a production PostgreSQL instance. The internal policy requires 24 characters, all four classes, ambiguous characters allowed. The generator with length 24 and all classes yields a 24-character password with entropy 24 × 6.52 ≈ 156 bits. The DBA copies the password into the corporate vault, then immediately edits pg_hba.conf to require certificate authentication for root and removes the password-based fallback.

Example 3, A passphrase-safe generator. Bob wants a long password he can read aloud to a colleague over the phone, so he enables the avoid-ambiguous toggle. The pool drops from 92 to 86, and he bumps the length to 22 to compensate. Entropy: 22 × log₂(86) ≈ 140 bits. The password is no harder to remember (he will not need to remember it) but it is dramatically easier to dictate.

Example 4, A legacy AT-command console. Carol's modem console accepts only alphanumeric passwords and rejects all symbols. She disables the symbols class; the pool drops to 62 (upper + lower + digits). With length 14, entropy is 14 × 5.95 ≈ 83 bits, well into the Strong band. The generator produces five 14-character strings, all of which the modem accepts.

Example 5, An API consumer secret. DevOps needs a 64-character string for a new service-to-service API token. The generator with length 64 and all classes yields a 64-character password with entropy 64 × 6.52 ≈ 417 bits. The vault stores the secret, and the CI/CD pipeline retrieves it via a short-lived workload identity token.

Common Attack Vectors

• Brute force. The defender's math wins. Two computational doublings of attacker hardware capacity add one bit to the brute-force schedule. Increasing length by 4 characters adds ~26 bits, which is worth about a decade of attacker hardware growth.
• Dictionary. A random password has no dictionary entry. The attacker must fall back to brute force.
• Mangling rules. Sophisticated crackers try password → p@ssw0rd → Password1 → P@ssw0rd! → .... None of these targets a random output.
• Credential stuffing. The attacker tries leaked passwords from other breaches. Since the password is fresh and unique, this vector fails.
• Phishing. The attacker tricks the user into typing the password into a fake site. The fix is a password manager that autofills only on the real domain. Random passwords are not a defence against phishing; they make the consequences of a single leak smaller.
• Keylogger. The attacker captures the password as it is typed. Random passwords do not help; the fix is a password manager and two-factor authentication.
• Shoulder surf. The attacker reads the password over the user's shoulder. The fix is to use the copy button rather than typing or reading aloud; the avoid-ambiguous toggle does not help against this vector but reduces the cost if it happens.
• Server breach. The attacker compromises the site that stores the password hash. The fix is for the site to use Argon2id or bcrypt with a high work factor, and to salt the hash. A random password is still the best input to these hashes.

Password Managers and Where the Generator Fits

The recommended workflow in 2024 is to keep dozens of strong unique passwords in a password manager (Bitwarden, 1Password, KeePass, Apple Passwords, Google Password Manager) and to memorise only one master password. The job of a random password generator is to populate the password manager with strong inputs for each account. The generator's role is small but important: it is the source of entropy that the password manager then stores, autofills, and audits. When the password manager's built-in generator is unavailable (because the master password is locked, or the device is offline), a client-side web generator like this one is a good fallback.

master password itself, the entropy budget is higher because the password is reused across the entire vault. A 24-character random password with all classes enabled is comfortable for a master password. Some users prefer a diceware-style passphrase (5 to 7 random words from a 7,776-word list) for master passwords because of the typing comfort and the unambiguous memorability. The trade-off is length: a 5-word diceware passphrase is 5 × log₂(7776) ≈ 64 bits, less than an 18-character random password. Pick six or seven words if you go the diceware route.

Frequently Asked Questions

Q: How long should my password be? A: For an everyday consumer account, 14 to 16 characters is the modern minimum. NIST SP 800-63B recommends a minimum of 8 characters with no upper bound, but the entropy-based recommendation from the same document is 30 bits minimum and 80 bits preferred for human-memorised secrets. For machine-generated secrets stored in a password manager, push the length higher, 20 to 24 characters is a comfortable standard. For root credentials, API tokens, and database administrator passwords, 24 characters or more is conventional.

Q: Is a long password with all classes enabled unbreakable? A: No password is unbreakable in the absolute sense. A 16-character password with all four classes has about 104 bits of entropy, which is beyond the reach of any brute-force attack possible with current technology (the entire global Bitcoin hashrate sustained for billions of years would be required to have a 50% chance of guessing one). But no password is proof against phishing, keyloggers, shoulder-surfing, or a server breach. The defender's job is to choose entropy that exceeds the realistic attack budget, and 80+ bits is the standard target for any account that matters.

Q: Why do you use crypto.getRandomValues instead of Math.random? A: Math.random is a pseudo-random number generator that is not cryptographically secure. Its output is predictable if an attacker obtains a few outputs and reverse-engineers the internal state. crypto.getRandomValues is backed by the operating system's CSPRNG (Linux getrandom, macOS SecurityRandom, Windows BCryptGenRandom) and is suitable for cryptographic key generation. Using Math.random for password generation is a common bug in tutorials and produces passwords that look random but are practically guessable.

Q: Where do the generated passwords go? Are they logged anywhere? A: Nowhere. The generator runs in your browser. The password is computed in JavaScript memory and rendered to the page. There is no fetch call, no analytics call, no localStorage write, no IndexedDB write, no service-worker message. Closing the page destroys the password. The only place the password goes is wherever you paste it, your password manager, an env file, a config.

Q: Do I need to include a symbol, uppercase, lowercase, and digit? A: No. NIST SP 800-63B retired the old composition rules in 2017. Modern guidance is to focus on length and entropy rather than the mix of character classes. A 20-character lower-only password and a 12-character all-classes password have roughly the same entropy. The composition rules live on in legacy systems; enable the classes those systems require.

Q: Is it safe to use this generator on a public computer? A: The generation itself is safe, the password never leaves your browser. The risk on a public computer is the clipboard: copying the password leaves it in the system clipboard, where a keylogger or a malicious program can read it. On a public computer, prefer to type the password by hand from the screen rather than copying it, and clear the clipboard immediately afterwards. Better: do not generate passwords on a machine you do not trust.

Q: Can I generate a passphrase made of random words instead? A: This generator produces random-character passwords, not random-word passphrases. For diceware-style passphrases, see the dedicated passphrase generator on this site. The trade-off is length vs. memorability: a five-word diceware passphrase is about 64 bits of entropy and is much easier to type from memory than a 16-character random password, but the random password at 104 bits is more secure if stored in a password manager.

Q: How does this compare to the password generator in my browser or password manager? A: Most browser and password-manager generators are also cryptographically secure, they use the same crypto.getRandomValues or pepper it with system entropy. The differences are usually in the UI defaults, the available character classes, and the option to exclude ambiguous characters. This generator's edge is the auditable surface: a single self-contained component with no network calls, no analytics, no telemetry, and a clear source citation to NIST SP 800-63B.

Q: What is the difference between this tool and the existing Password Generator on the site? A: The existing Password Generator on this site is the legacy entry for the password-generator slug, which preceded the centralised catalogue migration. This new tool is the canonical entry under the more descriptive random-password-generator slug and aligns the structure with the other modern generators (UUID, hash, JWT, dice roller): inline controls, entropy indicator, no server-side math, and the same Web Source citation pattern. Slug password-generator remains for backward compatibility.

References

• NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, the canonical US guidance on password length, composition, and storage.
• NIST Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, the cryptographic DRBG standards that CSPRNGs in operating systems implement.
• RFC 4086, Randomness Requirements for Security, the IETF best-current-practice document on entropy sources for security.
• WebCrypto specification, W3C, the crypto.getRandomValues API referenced throughout this tool.
• OWASP Password Storage Cheat Sheet, the modern guidance on server-side password hashing (Argon2id, bcrypt, scrypt).
• IETF draft on the Diceware passphrase method, the alternative random-word strategy for memorable master passwords.