DigitalCalculators.net

Menu

Random Password Generator

Create secure, unique passwords using a cryptographic random generator. Tune length, character sets, and rules — then copy with one click.

Settings

6 128
Symbols set (editable):
Tip: Use a unique password per site and store it in a reputable password manager.

Strength

—
Entropy
—
Character Pool
—
Time to Crack (est.)
—
Estimates assume offline brute-force at scale; real-world safety also depends on storage and reuse habits.

🔹 Table of Contents

🔹 How the Random Password Generator Works

Hook: Strong passwords come from two things: length and unpredictability. This generator uses the browser’s cryptographic random source (window.crypto.getRandomValues) to choose characters from the sets you select, then estimates strength using information-theory entropy.

Entropy (bits) = L × log2(N)

  • L = password length
  • N = size of the character pool (e.g., 26 lowercase + 26 uppercase + 10 digits + symbols)

🔹 Character Pools

Toggle sets to expand the pool and increase randomness. Ambiguous characters (like O/0 and l/1) can be excluded to improve readability.

Set Characters Count
Lowercase a–z 26
Uppercase A–Z 26
Digits 0–9 10
Symbols (editable) ! @ # $ % ^ & * ( ) - _ = + [ ] { } ; : , . ? / varies

🔹 Worked Example (Entropy)

Suppose you choose lowercase, uppercase, and digits (26 + 26 + 10 = N = 62) with length L = 16:

Entropy = 16 × log2(62) ≈ 16 × 5.954 ≈ 95.3 bits

At ~95 bits, exhaustive brute-force is infeasible with current hardware assumptions. Increasing length to 20 pushes the entropy over 119 bits.

🔹 Guaranteeing Each Selected Type

When “Guarantee all selected types” is enabled, the generator first inserts at least one character from each chosen set, then fills the remaining positions randomly and shuffles, so every password still looks unpredictable.

Diagram showing password length and pool size increasing entropy
Illustration: Longer passwords and larger character pools increase entropy exponentially.

Related tool: If you’re experimenting with randomness concepts, try our Random Number Generator to see uniform selection in action.

🔹 Recommended Length & Settings by Scenario

Hook: Different accounts face different risks. Use the strongest practical settings where it matters most, and keep everything unique across sites.

Rule of thumb: increase length first, then expand the character pool.
Scenario Recommended Length Character Sets Options Entropy Example*
Email / Social 16–18 Lower + Upper + Digits (≈62) Guarantee types; avoid ambiguous 16 × log2(62) ≈ 95 bits
Banking / Crypto 20–24 Lower + Upper + Digits + Symbols (≈70–90) No duplicates; guarantee types 20 × log2(80) ≈ 127 bits
Work / Admin 18–24 Lower + Upper + Digits (+ Symbols if allowed) Follow policy; guarantee types 18 × log2(62) ≈ 107 bits
Wi-Fi (Router) 20–24 Lower + Upper + Digits Readable on label (avoid ambiguous) 22 × log2(62) ≈ 131 bits
API Keys (where permitted) 24–32 All sets (policy-compliant) Store securely; rotate 24 × log2(80) ≈ 152 bits

*Entropy examples assume typical pool sizes: 62 for a–z, A–Z, 0–9; 70–90 when symbols are included (varies by policy). Exact entropy depends on your selected options.

🔹 Aligning with Site Password Policies

Some websites enforce specific rules (e.g., “must include symbols” or “max length 20”). Use the generator’s options to match those constraints while maintaining length and randomness. If symbols cause issues, enable Increase readability to limit to a friendly subset.

🔹 Rotation & Recovery

  • Rotate high-value credentials on a schedule or after any breach notice.
  • Use unique passwords everywhere; if one site leaks, others remain safe.
  • Set up recovery methods (MFA, backup codes) and store them securely.

Pro tip: For long, memorable wireless keys, consider 20–24 characters with letters and numbers only; it remains printable while offering high entropy.

🔹 Practical Workflow for Using Generated Passwords

Hook: Strong passwords only protect you if you store and use them correctly. Follow this quick, repeatable flow whenever you sign up or rotate credentials.

  1. Generate a long, unique password in the tool above (e.g., 20–24 chars with letters, numbers, and symbols if allowed).
  2. Copy and save it directly into a reputable password manager (never plain text notes or email drafts).
  3. Enable multifactor authentication (prefer app-based codes or a hardware key over SMS).
  4. Save recovery codes in a separate, secure location (password manager secure notes or encrypted drive).
  5. Rotate credentials after breach notifications or policy updates.
Never reuse passwords across sites. One breach can cascade into account takeovers elsewhere.

🔹 Storage Options Compared

Method Pros Risks / Cons Best For
Password manager (cloud sync) Cross-device sync; auto-fill; breach alerts Master password security is critical; pick a reputable vendor Daily personal & work accounts
Password manager (local-only) No vendor cloud; full local control Manual backups; device loss risk Advanced users; offline environments
Encrypted file (e.g., VeraCrypt/BitLocker) Simple vault for exports & recovery codes Manual key management; human error Backup of secrets & recovery info
Paper backup (sealed) Offline; resilient to malware Physical theft/fire; needs safe storage Master secrets & recovery codes

🔹 MFA Tiers (Choose the Strongest Available)

  • Hardware security key (FIDO2/WebAuthn): Phishing-resistant; ideal for critical accounts.
  • Authenticator app (TOTP): Good balance of security and convenience.
  • SMS codes: Better than nothing, but vulnerable to SIM-swap and phishing.
Checklist showing password manager, MFA, and recovery code best practices
Setup checklist: unique passwords in a manager, app or hardware-key MFA, and offline recovery codes.

Related tool: To understand randomness and sampling, try our Dice Roller for another view of uniform selection.

🔹 Worked Examples & Edge Cases

Hook: Small option changes can move your entropy by dozens of bits. These examples show how length and pool size interact, plus what “no duplicates” and “avoid ambiguous” really change.

Formula: Entropy (bits) = L × log2(N), where L is length and N is the character pool size.
Example Settings Pool N Length L Entropy (≈) Crack Time (rough) Comments
a–z only 26 16 16 × log2(26) ≈ 75.2 bits Years → centuries Usable for low-risk, but adding more sets is better.
a–z, A–Z, 0–9 62 16 16 × log2(62) ≈ 95.3 bits Centuries → beyond human timelines Good baseline for most accounts.
a–z, A–Z, 0–9, symbols ~80 20 20 × log2(80) ≈ 127.1 bits Computationally infeasible Great for banking/admin if symbols allowed.
a–z, A–Z, 0–9 (avoid O/0/l/1/I) ~57 18 18 × log2(57) ≈ 102.7 bits Computationally infeasible More readable while still very strong.
All sets + “no duplicates” ~80 (no repeats) 24 24 × log2(80) ≈ 152.6 bits Infeasible No repeats slightly reduces convenience but is extremely strong.

🔹 Edge Cases & What to Do

  • Website blocks certain symbols: Enable “Increase readability” to switch to a friendly subset (e.g., !@#$%+=?) or turn symbols off and raise length by +2 to +4.
  • Max length is low (e.g., 16): Keep all sets on and guarantee types to squeeze more entropy from a smaller L.
  • Copy/paste restrictions: Use “Copy” per row or “Download .txt”, then paste; if blocked, temporarily reveal and type, but prefer managers to avoid typos.
  • Printer-friendly Wi-Fi key: Use 20–24 characters, letters + digits, avoid ambiguous. High entropy and easy to read from a label.

Reminder: Never publish or reuse any example password you see online. Always generate a fresh one in the calculator above.

🔹 What Our Strength Estimates Assume

Hook: Crack-time numbers are ballpark figures, not guarantees. They help you compare settings and make informed decisions.

  • Randomness: Passwords are generated with window.crypto.getRandomValues (CSPRNG). This assumes no bias and uniform selection across your chosen character pool.
  • Attacker model: Offline brute-force with high-end GPUs or clusters. We show times for several guess rates to highlight sensitivity.
  • No knowledge leaks: We assume attackers don’t know your policy (e.g., “no duplicates”) or that you chose a memorable pattern. If they do, effective entropy drops.
  • Storage matters: Strong hashing (argon2id/scrypt/bcrypt) + unique per-account passwords + MFA drastically reduce real-world risk even if a site is breached.
Increase length before complexity. Adding just 2–4 characters often beats toggling more symbols.

🔹 Entropy vs. Estimated Crack Time

The table below shows very rough averages for different attacker speeds. Real outcomes vary by hash algorithm, implementation, and attack optimizations.

Entropy (bits) ~109 guesses/sec ~1012 guesses/sec ~1015 guesses/sec
60 ~12 days ~17 minutes ~1 second
80 ~119 years ~44 days ~1 hour
100 ~122,000 centuries ~122 centuries ~1.2 years
120 ~1.3×1013 years ~13 million years ~13,000 years
140 ~1.4×1019 years ~1.4×1016 years ~1.4×1013 years

🔹 Practical Takeaways

  • Every +1 bit doubles work. Pushing from ~95 to ~120 bits moves attacks from “impractical” to “astronomical.”
  • Length scales predictably. If your character pool is N, adding one character adds log2(N) bits.
  • Site caps: If a site limits length or characters, raise length to the maximum allowed and keep all sets that pass validation.
  • Defense in depth: Use unique passwords, strong hashing (site-side), and MFA. Consider rotating high-value credentials periodically.

Related tool: Need to generate random values for testing? Use our Random Number Generator.

🔹 Standards & Best Practices Overview

Hook: Modern guidance emphasizes long, random, unique passwords, plus multifactor authentication and user-friendly policies. This section maps common standards to practical settings you can apply with the generator above.

Prioritize length and randomness, avoid composition rules that reduce usability, and never reuse passwords across sites.

🔹 NIST Essentials (SP 800-63B highlights)

  • Encourage length: Allow at least 64 characters where possible; long random strings or passphrases are recommended.
  • No arbitrary complexity rules: Don’t force weird mixtures that frustrate users; randomness and length matter more.
  • Block known-compromised strings: Check against breach corpuses where feasible.
  • Store safely: Use strong hashing (e.g., argon2id, scrypt, or bcrypt) and rate-limit authentication attempts.

🔹 UK NCSC Essentials

  • Length over complexity: Longer passwords are more resilient to brute-force.
  • Reduce password fatigue: Avoid frequent forced rotations; change after compromise or risk events.
  • Support MFA: Add phishing-resistant factors where feasible.

🔹 Policy → Generator Settings Mapping

Policy Goal What It Means Generator Settings
Prefer length More bits of entropy at a predictable rate Set length 18–24+ for important accounts
Avoid brittle complexity rules Don’t force patterns users can guess or reuse Enable Guarantee all selected types; keep randomness high
Block obvious/compromised strings Prevent reuse of known-breached passwords Use random generation; never base on names/dates
Improve usability Reduce typos and lockouts Use Avoid ambiguous for labels/Wi-Fi; consider readability subset
Defense in depth MFA + unique per site + secure storage Combine with a password manager and MFA

🔹 Organization Checklist

  • Allow long passwords and paste in login fields.
  • Adopt breach-password screening during resets/registration.
  • Use modern hashing and rate-limiting on auth endpoints.
  • Enable MFA with hardware keys or authenticator apps.
  • Publish clear, user-centric password guidance.

Takeaway: The strongest, most user-friendly approach is to generate long, random passwords, manage them with a reputable tool, and add MFA—aligned with modern standards.

🔹 Passphrases vs. Random Strings

Hook: Long, random strings are excellent for managers and APIs. Passphrases (multiple random words) can be easier to type and remember—useful when a manager isn’t available.

If a site allows long credentials, both approaches can achieve high entropy. Choose the one that fits your workflow without encouraging reuse.

🔹 Comparison

Method How It’s Built Strength Factors Pros Cons Good For
Random string Uniformly random characters from a pool (a–z, A–Z, 0–9, symbols) Length L and pool size N ⇒ entropy ≈ L × log₂(N) Very high entropy per character; great for copy/paste and managers Hard to memorize; may be restricted by some site rules Primary accounts, API keys, admin credentials
Passphrase (random words) Uniformly chosen words from a dictionary list (e.g., 7k–20k words) Words W and list size D ⇒ entropy ≈ W × log₂(D) Human-typable; fewer symbols; can be very long Requires genuinely random word selection; spacing/symbol rules vary When managers aren’t possible or for device unlock phrases

🔹 Sizing Examples

  • Random string: 20 chars from N ≈ 62 ⇒ entropy ≈ 20 × log₂(62) ≈ 119 bits.
  • Passphrase: 6 words from D = 7,776 (≈ Diceware) ⇒ entropy ≈ 6 × log₂(7776) ≈ 6 × 12.9 ≈ 77 bits. Add 2 more words (8 total) ⇒ ≈ 103 bits.

🔹 Practical Tips

  • Prefer length first. Adding one character to a random string adds log₂(N) bits; adding one word to a passphrase adds log₂(D) bits.
  • Avoid meaningful phrases, quotes, or song lyrics—these are not uniformly random and reduce effective entropy.
  • If a site blocks spaces, use hyphens or periods between words (if allowed), or switch to a random string from the generator above.
  • Never reuse a passphrase or random string between accounts.

Takeaway: For most users, randomly generated strings managed by a password manager are ideal. Use random passphrases only when you must type and remember the secret yourself, and keep them long enough to reach strong entropy.

🔹 Policy Starter for Teams

Hook: If you run an app or manage a company domain, align your password policy with modern guidance and make it easy for users to succeed securely.

Goal Recommendation Notes
Length Accept 64+ chars; encourage 18–24+ for high-value accounts Longer is better than quirky composition rules
Composition Allow any printable characters; don’t force patterns Optionally require “at least 3 sets” for legacy systems
Paste & Copy Allow paste in login & reset forms Supports managers; reduces errors and lockouts
Blocklists Screen against breached/common passwords Reject on registration/reset; log reason generically
Rotation No forced periodic changes Rotate after compromise, role change, or policy updates
MFA Prefer FIDO2/WebAuthn or TOTP Provide backup codes; support multiple factors

🔹 Server-Side Hashing Parameters (Guidance)

Use a memory-hard, adaptive KDF. Suggested starting points (adjust for your hardware and latency budget):

Algorithm Params (example) Target Verify Time Notes
argon2id memoryCost ≈ 64–256 MB, iterations 2–4, parallelism 1–4 ~100–300 ms/server Resists GPU/ASIC; tune per deployment
scrypt N=2^14–2^16, r=8, p=1–2 ~100–300 ms/server Memory-hard; widely supported
bcrypt cost=12–14 ~100–300 ms/server Legacy-friendly; avoid truncated input limits

Always use a unique, per-password salt and a modern password hashing library. Never store plain hashes without salts; never roll your own crypto.

🔹 UX Anti-Patterns to Avoid

  • Blocking paste in password fields.
  • Arbitrary composition rules (e.g., “must include exactly one symbol”).
  • Overly strict rate limits on reset flows that lock out legitimate users.
  • Displaying detailed rejection reasons that help attackers craft inputs.

🔹 Integrating This Generator in Internal Docs

  • Link this calculator from onboarding and “Create Account” guides.
  • Pre-fill defaults for your policy (e.g., length 20, guarantee types, avoid ambiguous).
  • Provide one-click guidance on enabling MFA and storing recovery codes.

Related internal task: After setting policy, run a security review of registration and reset endpoints (rate limiting, CAPTCHA for abuse, and secure email flows).

🔹 Troubleshooting Common Errors

Hook: Some websites enforce strict password validators. Use the tips below to pass validation without sacrificing too much entropy.

Issue Seen Why It Happens What To Change
“Invalid characters” Site blocks certain symbols or whitespace Enable Increase readability (friendly subset) or disable symbols; add +2 to +4 length
“Too long” Max length cap (e.g., 16 or 20 chars) Use all allowed sets and Guarantee types; keep at the site’s max length
“Must include symbol/uppercase/digit” Composition rule enforced Toggle the required sets and keep Guarantee types on
“Repeated characters not allowed” Policy forbids duplicates Enable No duplicate characters; if it fails, reduce length or expand pool
Copy/paste blocked Login form prevents paste Use the password manager’s autofill or reveal and type carefully (prefer manager to avoid typos)
“Similar to previous” History/similarity checks in place Generate a fresh password (new random seed) and consider a longer length

🔹 Validator-Friendly Settings Checklist

  • Start with length 20; if rejected, drop in steps (20 → 18 → 16) while keeping all sets on.
  • If symbols fail, switch to the friendly subset or remove symbols and add +2–4 length.
  • Leave Guarantee all selected types enabled to satisfy typical composition rules.
  • For printed Wi-Fi labels, use letters + digits and Avoid ambiguous to reduce misreads.
  • For stringent “no duplicate” policies, keep length ≤ pool size and enable No duplicate characters.
When in doubt: maximize length first, then adapt the character sets just enough to pass validation.

🔹 Fast Fix Workflow

  1. Try your normal strong preset (e.g., 20 chars, all sets, guarantee types).
  2. If blocked, toggle Increase readability or remove symbols and add +2–4 length.
  3. If still blocked, reduce length to the site’s max and keep all required sets enabled.
  4. Save to your password manager, enable MFA, and store backup codes securely.

Security note: Do not use memorable patterns to appease validators. Always keep randomness high and avoid reuse across sites.

🔹 Frequently Asked Questions

Yes. The generator uses the browser’s window.crypto.getRandomValues API (CSPRNG) to draw uniformly random bytes and map them onto your selected character pool.
Use 20–24 characters with lowercase, uppercase, digits, and (if allowed) symbols. Keep “Guarantee all selected types” on. If symbols are disallowed, add 2–4 characters to compensate.
Generally yes. Length increases entropy at a predictable rate. Prioritize length first, then expand the character pool as needed for policy compliance.
It removes look-alike characters (O/0 and l/1/I) to reduce transcription errors on labels/printed keys, with a small drop in pool size.
Only if a site requires it. Disallowing duplicates can constrain length if the pool is small. Random passwords remain very strong even with repeats.
Both can be strong when randomly chosen and sized properly. Random strings pack more entropy per character; passphrases can be easier to type. Prefer a manager; use long random passphrases if you must memorize.
They’re coarse offline brute-force approximations for comparison. Real safety also depends on site hashing (argon2id/scrypt/bcrypt), rate limiting, unique passwords, and MFA.
Use a reputable password manager with sync and MFA. Save recovery codes separately (secure notes or an encrypted backup).

🔹 References & Sources

The content and calculations on this page are based on widely accepted security guidance and technical documentation. Exact links are provided for verification and further reading.

Source What We Used Link
MDN Web Docs — Web Crypto API: getRandomValues() Browser cryptographic random number generation used by the calculator developer.mozilla.org/.../getRandomValues
NIST SP 800-63B — Digital Identity Guidelines Modern password policy guidance: length over arbitrary complexity, breach list checks pages.nist.gov/800-63-3/sp800-63b.html
UK NCSC — Password Guidance Practical recommendations: long passwords, reduced rotation, MFA ncsc.gov.uk/collection/passwords
OWASP — Password Storage Cheat Sheet Server-side hashing best practices (argon2id/scrypt/bcrypt, salting, parameters) cheatsheetseries.owasp.org/.../Password_Storage_Cheat_Sheet.html
EFF — Diceware Passphrase List Entropy estimates for random-word passphrases eff.org/dice
Calculator.net — Password Generator (competitor) Feature comparison and UX benchmarking calculator.net/password-generator.html
Academic/InfoSec Basics Entropy model used in explanations: Entropy ≈ L × log₂(N) wikipedia.org/wiki/Password_strength
Illustrations in this page are original to DigitalCalculators.net. If you replace the placeholder image URLs, keep descriptive alt text for accessibility.