Password Generator

Password Generator

Generate strong random passwords with letters, numbers, symbols. Customizable length and complexity. Free secure password generator online

Password strength is not about length, character classes, or memorability — it is about entropy. A 12-character random password drawn from 95 printable ASCII characters has 79 bits of entropy. A 20-character password using only lowercase letters has 94 bits. This generator uses crypto.getRandomValues from the Web Crypto API (CSPRNG, not Math.random) and exposes the actual entropy of each output so you can choose deliberately instead of guessing.

Entropy, in one paragraph

Entropy measures unpredictability. For a password of length L drawn uniformly from an alphabet of size N, entropy in bits is L × log2(N). A 12-character password from a 95-symbol alphabet has 12 × log2(95) ≈ 79 bits. Doubling the alphabet adds one bit per character. Adding one character adds log2(N) bits. The headline number on most password-strength meters is just this calculation in disguise — but it is only valid if each character is truly random, which is exactly what crypto.getRandomValues gives you.

For context: 60 bits is roughly the threshold where offline brute force becomes infeasible against a fast hash (SHA-256 on a GPU rig). For a slow password hash (Argon2id, scrypt), 50 bits is already overkill. For online attacks limited by rate limiting, 35 bits is plenty.

Working example: comparing two presets

Input

Preset A: 12 chars, lowercase + digits (alphabet = 36)
Preset B: 16 chars, lowercase only (alphabet = 26)

Output

A entropy: 12 × log2(36) ≈ 62 bits
B entropy: 16 × log2(26) ≈ 75 bits

Winner: B, despite using a smaller alphabet — length dominates.

This is why passphrases like "correct-horse-battery-staple" can beat random strings: four words from a 7776-word list = 51 bits, five words = 64 bits.

Practical settings

  • For password manager entries that you never type: 24+ random characters from the full printable ASCII alphabet. ~158 bits. Future-proof.
  • For Wi-Fi passwords you may need to type on a phone: 16 alphanumeric characters. ~95 bits. No symbols to fight with.
  • For master passwords (the one you actually remember): use a passphrase tool, not this one. Random characters at memorable length are weaker than well-chosen words.
  • For server-side API secrets: 32 hex characters (= 16 bytes = 128 bits). Length is consistent, parsing is trivial, no escaping concerns.

When to reach for this tool

  • You need a one-off strong password right now and your password manager is on another device.
  • You are generating service-account credentials for a CI pipeline and need to paste them into a vault.
  • You are writing test fixtures that need realistic-looking but disposable credentials.
  • You want to demonstrate to a colleague that "P@ssw0rd!" has less entropy than "correct-horse-battery-staple" with actual numbers.

What this tool will not do

  • It will not store the password. Once you close the tab, it is gone. That is intentional — if you need to remember it, paste it into a password manager immediately.
  • It will not check leaked-credential databases. To verify a password has not appeared in a breach, use a Have-I-Been-Pwned-style k-anonymity API. Generated passwords are random enough that this is essentially a formality, but if you must check, do so separately.
  • It will not help if your site bans certain characters. Some legacy systems forbid > or # or quotes — adjust the character set explicitly in the options.

Generation happens entirely in your browser using window.crypto.getRandomValues. The password never crosses the network. Server-rendered password generators routinely log inputs and outputs — this one cannot, because there is no server.

Frequently asked questions

Is Math.random secure enough for passwords?

No. Math.random is a fast non-cryptographic PRNG seeded predictably. Outputs can be reconstructed if an attacker observes a few samples. Use crypto.getRandomValues for anything security-sensitive — which is what this tool does.

How long should my password be?

Long enough that brute force against the verifier's rate limit takes longer than the password's useful lifetime. For consumer apps with rate limiting, 12 truly-random characters is plenty. For offline attacks on a database leak, aim for 16+ characters from a full alphabet, or use a passphrase.

Do special characters actually help?

They add to alphabet size and therefore entropy, but only marginally. Going from 62-character alphabet (alphanumeric) to 95 (printable ASCII) adds about 0.6 bits per character. Adding two characters of length adds ~12 bits. Length beats character variety almost always.

Should I avoid look-alike characters (l, 1, I, O, 0)?

Only if a human will read the password from a screen or paper. Excluding them costs about 2-3 bits of entropy, recovered by adding one more character. Most password managers handle this for you.

Is a passphrase stronger than a random password?

At equal entropy, no — entropy is entropy. But for a given amount of brain effort, passphrases store more entropy in human memory. For master passwords, prefer passphrases. For machine-stored secrets, prefer random characters because they are shorter for the same strength.

Why does the same password show different "strength" on different sites?

Most online strength meters use heuristics (zxcvbn) that estimate guessability against a leaked-passwords database, not raw entropy. A random 12-character string scores low on length-based meters and high on zxcvbn. Trust the bit count, not the green bar.

Related tools

Last updated · E-Utils editorial team