SparkJSON

Password Generator

Generate strong passwords with a real entropy-based strength meter.

Select at least one character type
Very strong130.2 bits of entropy
20
Generated with crypto.getRandomValues (a cryptographically secure random source), never Math.random. Entropy is computed as log2(character pool size) × length — the real theoretical bit strength, not a cosmetic bar.
Advertisement

About Password Generator

Generate passwords using crypto.getRandomValues (never Math.random), with controls for length, character sets, and ambiguous-character exclusion. The strength meter computes actual bits of entropy from your chosen character pool and length rather than showing a cosmetic bar.

Every character in a generated password comes from crypto.getRandomValues, the Web Crypto API's cryptographically secure random number source — never Math.random, which is fast but explicitly not designed to be unpredictable and should never back anything security-related.

Character selection also avoids modulo bias: naively mapping a random 32-bit integer onto a character pool with `% poolSize` slightly favors some characters over others whenever the pool size doesn't divide evenly into 2^32. This tool uses rejection sampling instead, discarding the rare out-of-range values so every character in the pool has an exactly equal chance of being picked.

The strength meter is a real calculation, not a cosmetic bar: entropy in bits is log2(pool size) × length, the standard formula for the information content of a string drawn uniformly at random from a fixed alphabet. A 20-character password from a 94-character pool (lower + upper + numbers + symbols) works out to about 131 bits — astronomically harder to brute-force than the same length using digits alone (roughly 66 bits).

Frequently asked questions

Why does removing symbols lower the entropy number even at the same length?
Entropy depends on how many possible characters could appear at each position, not just how many characters are in the password. Removing symbols shrinks the character pool, which lowers log2(pool size) — and therefore the total bits — even though the password length hasn't changed.
Is crypto.getRandomValues actually more secure than Math.random?
Yes, meaningfully so. Math.random is typically backed by a fast, non-cryptographic pseudo-random algorithm (like xorshift128+) whose output can, in principle, be predicted from enough samples. crypto.getRandomValues is backed by your OS's cryptographically secure random number generator, the same category used to generate encryption keys.
Should I exclude ambiguous characters like 1, l, and I?
Only if a human will need to read and retype the password — for example off a printed card. It slightly reduces the character pool (and therefore the entropy for a given length), so if the password will only ever be pasted from a manager, leaving ambiguous characters in gives you marginally more entropy for the same length.