Password Generator

How it works

Pick a length and a character set. The widget draws each character uniformly from the active set using your browser’s Web Crypto API (crypto.getRandomValues) — the same source modern operating systems use to seed TLS sessions. We refuse to fall back to Math.random() if Web Crypto is unavailable; you’ll see an error instead of a quietly weaker password.

Rejection sampling guards against modulo bias, so every character has exactly the same probability of being picked. Constraints like no repeating and no sequential are applied at generation time, not after — there’s no chance of leaking a constraint-violating result into the output.

What makes a password strong (the honest answer)

The popular advice — “mix uppercase, lowercase, numbers, and symbols” — is a proxy for the real answer: entropy. Entropy comes from two inputs only: the size of the alphabet you’re drawing from, and the length of the password.

A concrete example: passw0rd! looks compliant. It has 9 characters, mixes case, includes a digit and a symbol — and it carries roughly 59 bits of entropy on paper. The problem is that password is the most common entry in the RockYou leak. Any attacker who hasn’t been asleep since 2009 starts with that wordlist and tries common substitutions (a→@, o→0) before bothering with brute force. Our RockYou check flags this case.

By contrast, a 10-character uniform draw like tH7@kp9LmQ gives you ~65 bits and isn’t in any common wordlist. The bit count is similar; the resistance to real attacks is not. Length beats complexity when you have to choose — adding one random character is worth more than swapping a letter for a similar-looking symbol.

Entropy explained

The formula is one line: bits = length × log₂(charsetSize). A charset of 95 printable ASCII characters at length 16 gives 16 × log₂(95) ≈ 105 bits. A 6-digit PIN gives 6 × log₂(10) ≈ 20 bits — which is why nobody should use a 6-digit PIN as a primary password.

What does “a bit of entropy” buy you in practice? Each bit doubles the average number of guesses an attacker has to try. Against MD5 at ~288 billion guesses per second on an RTX 4090, 20 bits (a million combinations) finishes in microseconds. 40 bits (a trillion) falls in about two seconds. 60 bits buys you about three weeks. 80 bits is 2⁸⁰ ≈ 10²⁴ — roughly 66,000 years on a single GPU, decades even against a thousand-GPU farm. The jump from 60 to 80 is not 33% more security; it’s a million times more.

One subtle point: the formula assumes the attacker doesn’t know any structure of your password. If you generate summer2024! through a wordlist-aware tool, the “charset” the attacker effectively faces is the wordlist size, not the 95-char ASCII space — closer to log₂(10,000) × 3 + log₂(50) ≈ 45 bits than the naive ~70 bits a uniform model would suggest. The numbers we surface assume uniform draws, which is what this generator actually does.

The categorical tiers we surface use the NIST-aligned boundaries:

• Weak — under 36 bits. Crackable offline in minutes on a modern GPU.
• Fair — 36 to 60 bits. Safe online, weak offline.
• Strong — 60 to 80 bits. Practically safe for most modern threat models.
• Very strong — 80 to 128 bits. The 16-character default lands here.
• Extreme — 128+ bits. Computationally unreachable with foreseeable hardware.

Crack time — what those numbers really mean

We show four scenarios, ordered from least to most attacker-friendly:

• Online (rate limited) ~100 guesses per hour. The realistic ceiling for a properly defended web login.
• Online (no throttle) ~1M guesses per second. What you face when a service forgets to rate-limit, or against an API endpoint that returns success/failure quickly.
• Offline (bcrypt, slow) ~14k guesses per second on a single RTX 4090 (hashcat v6.2.6, 2026 benchmarks). This is what an attacker faces if a password manager stores your secret with a deliberately slow hash.
• Offline (NTLM/MD5, fast) ~288.5 billion guesses per second on the same hardware. This is the grim worst case when a leaked database used a fast hash.

The honest framing: when you read “3 days” next to Offline (NTLM/MD5), the attacker isn’t guessing your password in three days — they’re testing every password at all positions of strength up to yours in three days, and yours is somewhere in that bucket on average.

The bcrypt-vs-MD5 distinction matters most to the people running the services you sign into. As a user you can’t pick the hash; you can only pick the password. But the gap between Offline (bcrypt, slow) at 14k/sec and Offline (NTLM/MD5, fast) at ~288.5 billion/sec is enormous: a fair-strength 50-bit password survives tens of thousands of years against bcrypt and falls in about an hour against MD5. The hash choice on the server is what turns a moderate password from “safe enough” into “leaked yesterday.” If a service publishes its password-storage practice (look for terms like bcrypt, scrypt, or Argon2), trust it more. Services that won’t say usually have a reason — and that reason is rarely good news.

When to use bulk mode

Bump Quantity above 1 and the widget switches to a table view with a Download CSV button. Three common use cases:

• Admins creating accounts in batch. Generate 50 distinct passwords, distribute them via your normal credential-handoff channel (not email).
• Developers populating seed data. Plausible-looking passwords for QA fixtures without recycling test123 across rows.
• Workshops and classes. Generate a CSV of starter credentials, hand it to participants, rotate after the first login.

The bulk CSV is built entirely client-side and never leaves your browser. Always rotate batch-issued passwords on first sign-in.

Common mistakes

Re-using one strong password across sites is a worse failure mode than using a slightly weaker, unique one. Reuse converts a single breach into a credential-stuffing campaign across every account you opened with that email. A password manager solves this; we recommend any reputable one — there’s no affiliate link here.

Trying to be clever by hand — a→@, o→0, e→3 — buys you nothing against modern attack tools. Every cracking dictionary applies those substitutions by default. The cost of pretending you’re being clever is that you’re slower to type and more likely to forget.

Sending a password over the channel you’ll later use to log in (e.g. a Slack DM to yourself) silently breaks defence-in-depth. If that channel is compromised, the password is too.

Trusting your own brain to generate randomness is the quiet failure mode. Ask any room of people to “pick a random number between 1 and 100” and 37 and 73 show up several times more often than the 1-in-100 baseline — a pattern so consistent that cracking tools have dedicated rules for it. Human choices cluster around keyboard patterns (qwerty, 1qaz2wsx), dates, names, and the middle of the keyboard. If you typed it without a generator, assume the attacker’s wordlist already considered it.

Trusting password meters on signup forms is another one. Most meters score on naive character-class checks — P@ssw0rd1 often scores “strong” because it ticks all the boxes, even though hashcat rule files crack it in seconds. The entropy number on this page is computed from the actual draw, not from pattern matching, which is why the two can disagree.