LiveWeb Crypto API (CSPRNG)

Secure Password Generator

Generate high-entropy, cryptographically secure passwords via browser CSPRNG.

Generate cryptographically strong random passwords with browser Web Crypto, unbiased rejection sampling, configurable character pools, and entropy metrics.

Workbench

Use Secure Password Generator

Ctrl/⌘ + Enter to regenerate

Generated Password

103.1 bits entropyVery Strong

Search Space1.09 × 10³¹

Character Pool88 unique characters

Randomness EngineWeb Crypto (CSPRNG)

Modulo BiasEliminated (Rejection Sampling)

Password Length

16characters

Presets:

Allowed Character Pools

Select at least one set

Uppercase (A-Z)26 letters (A, B, C...)Lowercase (a-z)26 letters (a, b, c...)Numbers (0-9)10 digits (0, 1, 2...)Symbols (!@#$)26 ASCII punctuation glyphs

Exclude ambiguous charactersAvoids 1, l, I, 0, O, o, and | for easy human transcriptionGuarantee representationEnsure at least 1 character from each selected pool (CSPRNG selection + shuffle)

Ready. Strong, cryptographically secure password generated locally in browser memory.

What it does

Built for the task, not the page view

Cryptographically strong randomness via window.crypto.getRandomValues() with no weak fallback
Length 8–128 with uppercase, lowercase, digits, symbols, and ambiguous-character exclusion
Uniform character selection with rejection sampling to avoid modulo bias
Optional class-presence guarantee using whole-candidate rejection sampling
Entropy/search-space metrics without deterministic crack-time promises

Inputs & outputs

Accepts

Password Generation Options

Produces

Random PasswordEntropy Metric

Reference

Use it correctly

Browser CSPRNG Randomness

Password randomness comes from the browser Web Crypto API (crypto.getRandomValues), which provides cryptographically strong random values suitable for security-sensitive generation. EveryTools does not substitute Math.random or another weaker fallback if Web Crypto is unavailable.

Zero Modulo Bias via Rejection Sampling

Standard modulo arithmetic (byte % poolSize) introduces statistical bias whenever 256 is not an exact multiple of the character pool size. Our engine implements rejection sampling, discarding bytes in the remainder interval so that every allowed character has an identical, mathematically uniform probability of selection.

Honest Entropy Model vs. Sensational Crack Times

For unconstrained generation, entropy is L × log2(R). When the “ensure each selected class appears” option is enabled, the generator rejects whole candidates until the class requirement is satisfied and uses inclusion–exclusion to count that uniformly sampled valid set. We avoid exact crack-time promises because real attacks depend on the password storage scheme, attacker resources, and rate limits.

Ambiguous Character Exclusion & Usability

Visually confusing glyphs (such as 1, l, I, 0, O, and |) can be excluded to facilitate manual transcription on mobile screens and terminal consoles. Excluding ambiguous characters slightly reduces pool size (from 88 to 81) with a minimal loss of entropy (~0.12 bits/char) while virtually eliminating human entry errors.

NIST SP 800-63B & Modern Expiration Standards

NIST guidelines deprecate arbitrary periodic password expiration (such as mandatory 90-day resets), which research demonstrates leads to predictable incremental changes (e.g. Winter2025! to Spring2025!). Instead, passwords should be long, randomly generated, unique across services, and rotated only upon evidence of compromise.

Client-Side Secret Handling

Generated passwords remain exclusively in browser tab memory and are never written to localStorage, cookies, URL parameters, or analytics. Product analytics records only fixed UI event IDs (such as regenerate or copy), ensuring your credentials remain private to your local device.

Password Strength & Crack Time Reference

Brute-force resistance is governed by total combinations (R^L) and Shannon entropy (E = L × log₂(R)). The benchmark table below illustrates theoretical search spaces across typical password lengths and pool compositions:

Length	Character Pool Composition	Pool Size (R)	Entropy (Bits)	Search Space (Combinations)	Exhaustion at 100B H/s*
12 chars	Lowercase letters only (a-z)	26	~56.4 bits	9.54 × 10¹⁶	~11.0 days
12 chars	Alphanumeric (A-Z, a-z, 0-9)	62	~71.5 bits	3.23 × 10²¹	~1,023 years
12 chars	Full pool (letters, digits, symbols)	88	~77.5 bits	2.16 × 10²³	~68,400 years
16 chars	Lowercase letters only (a-z)	26	~75.2 bits	4.36 × 10²²	~13,800 years
16 chars	Alphanumeric (A-Z, a-z, 0-9)	62	~95.3 bits	4.77 × 10²⁸	~1.51 × 10¹⁰ years
16 chars	Full pool (letters, digits, symbols)	88	~103.4 bits	1.64 × 10³¹	~5.20 × 10¹² years
24 chars	Full pool (letters, digits, symbols)	88	~155.0 bits	2.69 × 10⁴⁶	Astronomical (>10²⁷ years)

*Threat Model Assumptions & Caveats: The exhaustion column assumes a hypothetical unthrottled offline brute-force rig calculating 100 billion hashes per second (10¹¹H/s), typical of a multi-GPU cluster attacking fast, unsalted hash digests (e.g., legacy MD5 or single-round SHA-256). In real-world enterprise architectures employing memory-hard password hashing algorithms (such asArgon2id, bcrypt, or scrypt), cracking speeds drop to thousands of hashes per second, exponentially increasing security. In contrast, online accounts with rate-limiting and account lockout policies render online brute force infeasible even for moderate entropy.

NIST SP 800-63B Guidelines Summary

Special Publication 800-63B from the National Institute of Standards and Technology (NIST) outlines modern digital identity authentication guidelines. Organizations should understand these key principles:

Length Over Arbitrary Complexity: NIST recommends supporting passwords up to at least 64 characters, allowing users and password managers to generate long credentials. While user-created passwords should be at least 8 characters, automated randomly generated passwords should ideally be 16 or more characters to maximize search spaces.
Deprecation of Mandatory Composition Rules: NIST advises against requiring specific mixes of uppercase, lowercase, numbers, and symbols for human-created passwords, as humans respond with predictable substitutions (e.g., Pa$$word1!). Machine-generated passwords from this tool, however, naturally sample from diverse character sets without predictability.
End of Arbitrary Periodic Rotation: Forcing users to change passwords on arbitrary calendar schedules (e.g., every 90 days) without evidence of compromise has been proven counterproductive. It leads to trivial modifications (e.g., Spring2025! to Summer2025!) rather than real security. Passwords should only be rotated upon known breach exposure or compromise.
Compromise Screening: Verifiers should screen new passwords against breach databases (such as Have I Been Pwned) to ensure credentials have not been previously leaked in public dumps.
No Blanket Compliance Claims: While our generator aligns with the cryptographic and entropy objectives of NIST SP 800-63B, using a generator alone does not constitute blanket compliance with federal standards or industry regulations (such as PCI DSS 4.0 or HIPAA), which enforce specific operational controls.

Ambiguous Characters & Memorability Trade-offs

When passwords must be read from a screen and typed manually—such as during temporary Wi-Fi setup, mobile device enrollment, or offline terminal recovery—certain characters present severe visual ambiguity:

Numeral 1 vs. Letter l vs. Letter I vs. Pipe |

In many sans-serif typefaces, digit 1 (one), lowercase l (el), uppercaseI (eye), and vertical pipe | are nearly indistinguishable, leading to repeated failed login attempts.

Numeral 0 vs. Letter O vs. Letter o

Numeral 0 (zero) and capital O (oh) appear almost identical unless the font features an explicit slashed or dotted zero. Lowercase o can also cause scale confusion.

The Entropy Trade-off: Toggling "Exclude ambiguous characters" removes 7 characters from the pool (reducing total characters from 88 to 81). For a 16-character password, entropy changes from103.4 bits to 101.4 bits—a negligible difference of just 2 bits that preserves complete cryptographic security while eliminating transcription frustration.

Password Managers vs. Multi-Word Passphrases: For everyday online services, passwords should be generated randomly and stored directly in a password manager (e.g. Bitwarden, 1Password, or browser vaults) so humans never need to memorize or transcribe them. For master passwords or full-disk encryption keys that must be remembered and typed regularly, multi-word Diceware passphrases (4 to 6 random words) provide high entropy with superior typing speed.

Web Crypto CSPRNG Architecture & Rejection Sampling

Most basic online generators suffer from two critical architectural vulnerabilities: predictable pseudo-random engines (such as Math.random()) and statistical skew (modulo bias). EveryTools eliminates both:

1. Browser CSPRNG Primitives

We exclusively use window.crypto.getRandomValues(). Web Crypto exposes cryptographically strong random values suitable for security-sensitive generation; the browser and operating system are responsible for the underlying entropy source. EveryTools does not substitute a timestamp-based generator or Math.random() when Web Crypto is unavailable.

2. Modulo Bias Elimination via Rejection Sampling

When mapping an 8-bit unsigned integer (0–255) into a character pool of sizeR (e.g., 26 or 88), naive modulo arithmetic (byte % R) creates statistical bias because 256 is rarely divisible byR. The remainder values 0 to(256 % R) - 1 have a slightly higher probability of selection (~11% skew for 26 characters).

Our engine implements rejection sampling: any byte value greater than or equal to256 - (256 % R) is discarded, and a new random byte is read. Every retained byte maps to an exact uniform distribution across all character indices with zero bias.

3. Rigorous Combinatorial Shannon Entropy

When characters are drawn independently from pool size R, entropy is precisely E = L × log₂(R) bits. When pool guarantee is enabled, our engine uses arbitrary-precision BigInt arithmetic to compute the exact search space via the Principle of Inclusion-Exclusion, ensuring displayed metrics reflect true combinatorial reality.

4. Uniform Class-Constrained Generation

When “ensure each selected pool” is enabled, the generator samples a complete password uniformly from the combined character pool and rejects the whole candidate if any selected class is missing. Conditioning a uniform source this way keeps every accepted password in the valid set equally likely, which is why the inclusion–exclusion search-space calculation above matches the actual output distribution.

Local Secret Handling & Privacy Verification

EveryTools operates under a strict client-side isolation model. Your credentials never traverse the internet:

Volatile Memory Only: Generated passwords exist solely in browser RAM within your current tab. They are never persisted to localStorage, sessionStorage, cookies, indexed databases, or URL query strings.
Zero Transmission: No password, seed, option payload, or hash is ever sent to an EveryTools backend server or third-party API.
Privacy-Decoupled Analytics: Product telemetry records only fixed interface action IDs (e.g.tool_action: regenerate, tool_action: copy). The analytics beacon never receives tool inputs or generated values.

Independent DevTools Network Audit Instructions

You can independently verify that generated passwords never leave your browser:

Open your browser Developer Tools by pressing F12 (or Ctrl+Shift+I / Cmd+Option+I).
Click on the Network tab and check the Preserve log box.
Click the ⟳ Regenerate button or drag the length slider multiple times.
Observe that zero network requests are initiated for password generation.
When clicking Copy, observe that the only outbound beacon is a lightweight event tag (/__event?event=tool_action&action=copy&tool=password-generator) containing zero credential payloads.

Frequently Asked Questions

Is it safe to generate passwords in a web browser?: Yes, provided the site uses genuine client-side Web Crypto APIs without server communication, does not cache passwords in browser storage, and is delivered over secure HTTPS. Because all computation executes locally within your browser tab sandbox, no remote entity can observe the generated strings.
What is the minimum recommended password length today?: For randomly generated machine passwords, a length of 16 characters is the contemporary standard recommendation. It yields over 100 bits of Shannon entropy, rendering offline brute-force attacks computationally impossible for decades. For critical master passwords or cryptographic signing keys, 24 to 32 charactersis recommended.
Should I include special symbols in my passwords?: Including punctuation symbols expands the character pool from 62 to 88, adding approximately 0.5 bits of entropy per character. However, length has a far greater impact on entropy than complexity: a 20-character alphanumeric password (~119 bits) is significantly stronger than a 12-character complex password with symbols (~77 bits). Some legacy systems restrict specific symbols, in which case a longer alphanumeric password is an ideal alternative.
Why is periodic forced password expiration deprecated?: Security authorities including NIST, Microsoft, and the UK NCSC deprecate routine forced expiration (e.g. mandatory 90-day resets). Research proves that when forced to change passwords frequently without an actual breach, users make predictable pattern modifications (e.g., changing Winter2025! to Spring2025!). Strong, unique, randomly generated credentials stored in a password manager should only be changed when there is evidence of an actual credential exposure.

Explore EveryTools