Password Generator
Create secure passwords using crypto-random generation. Choose length, character types, exclude ambiguous characters and batch-generate multiple passwords. Runs locally.
Updated July 11, 2026
100% Private & Secure
This tool runs in your browser.
Your data is never uploaded or stored.
Click Generate to create passwords.
Options
How to use
- 1
Set password length and character options.
- 2
Click Generate.
- 3
Copy the password to your clipboard.
When to use it
Onboarding a new service account
Database replicas, CI deploy keys, and SMTP relays all need a credential you set once and store in a vault. A 24-character generator output gives you ~159 bits of entropy — strong enough that brute force is physically impossible, yet copy-paste friendly.
Resetting access after a breach
When an employee leaves or a secret leaks, you rotate every credential they touched. Batch-generating 20 passwords at once lets you update the vault entry, the service config, and the audit log in a single pass.
Choosing a memorable passphrase
For human-typed logins, a long passphrase beats a short complex one. Generating a 5-word sequence from a wordlist reaches over 60 bits of entropy while remaining far easier to type and remember than Xq9!kZ.
Generating API secrets and tokens
Server-to-server shared secrets should be high-entropy and long (32+ characters from the full printable ASCII set). A generator using the platform CSPRNG produces output indistinguishable from random — the property you want for bearer tokens.
How it works
Entropy: the math that actually makes a password strong
Password strength is measured in entropy, expressed in bits: H = log2(NL) = L × log2(N), where N is the alphabet size and L the length. Each additional bit doubles the search space, so 80 bits means roughly 280 ≈ 1.2×1024 guesses.
Two practical consequences fall out of this. First, length dominates: adding one character to a 94-symbol password adds ~6.6 bits, so a 16-character random string (~106 bits) is stronger than an 8-character one (~53 bits) no matter how exotic the symbols. Second, alphabet size is a multiplier, not a magic shield — forcing a symbol into an otherwise short password adds less than one extra character of length would.
- Lowercase letters: N = 26 → ~4.7 bits per character
- Mixed case + digits: N = 62 → ~5.95 bits per character
- Full printable ASCII: N = 94 → ~6.55 bits per character
- A random 16-character ASCII password ≈ 105 bits — strong against any offline attack
Why CSPRNG matters — and Math.random does not
A generator is only as random as its source. Math.random() and similar PRNGs are predictable: given enough output, an attacker can reconstruct the internal state and predict every past and future value. For game graphics or A/B testing that is fine; for a password it is fatal.
The crypto.getRandomValues() API (Web Crypto) and Node's crypto.randomBytes() draw from a cryptographically secure PRNG seeded by OS entropy. OWASP's Authentication Cheat Sheet mandates a CSPRNG for any security-sensitive value precisely because predictability collapses the entropy guarantee — a 32-character password from Math.random() may have far fewer than 32 characters of real strength.
// Secure: unbiased index into an alphabet, no modulo skew
const alphabet = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz23456789';
const bytes = new Uint32Array(length);
crypto.getRandomValues(bytes);
let pw = '';
for (let i = 0; i < length; i++) pw += alphabet[bytes[i] % alphabet.length];The NIST shift: length over forced complexity
For decades the conventional rule was "8 characters, upper, lower, digit, symbol." NIST SP 800-63B (Rev. 4) retired that. The current guidance: accept passwords up to at least 64 characters, do not impose mandatory composition rules, and screen new passwords against known-breached lists instead.
The reasoning is empirical. Forced complexity produces predictable mutations (Summer2024!, Password1!) that humans reuse and attackers already model. Length — especially in passphrases — adds entropy that is genuinely hard to guess, while being easier for humans to remember and type. The generator here follows that philosophy: dial length up before you reach for exotic symbol sets.
Common mistakes & edge cases
Passwords generated with Math.random() feel "random enough"
They are not cryptographically random. Math.random() is deterministic from a seed an attacker can recover. Use crypto.getRandomValues() (browser) or crypto.randomBytes() (Node) for any credential.
Modulo bias skews the character distribution
Doing byte % alphabet.length when 256 is not a multiple of the alphabet size makes low indexes slightly more likely. Reject bytes above the largest multiple of alphabet.length and redraw, or use rejection sampling.
Password rejected by a site for "missing special character"
Legacy policy. Either enable the symbols option, or lengthen the password — a 20-character alphanumeric string is stronger than the 8-character mixed policy the site is enforcing.
A reused password shows up in a breach database
Never reuse generated credentials across services. Generate a fresh one per site and store it in a password manager; screen new passwords against a breached-password list (k-anonymity API) as NIST recommends.
Frequently Asked Questions
Are the passwords truly random?
Can I generate multiple passwords at once?
References & further reading
Related reading
What actually makes a password strong
Entropy, length versus complexity, and why a long random password beats a short clever one — with the math that explains it.
JWT Security Checklist: What to Verify Before Trusting a Token
A concrete checklist for verifying JWTs: algorithm allowlists, the alg=none attack, expiry and clock skew, iss/aud claims, key rotation, and safe storage.
SHA-256, Salt, and Why a Raw Hash Fails Your Passwords
Why SHA-256 is excellent for file integrity but catastrophic for passwords — and how bcrypt, scrypt, and Argon2id fix the speed problem.