Password Generator

The strength readout is computed, not estimated. The generator assembles a character pool from whichever sets you enable — 26 uppercase letters, 26 lowercase letters, 10 digits, and 27 symbols — and multiplies your chosen length by the base-2 logarithm of the pool's size (the calculateEntropy function in src/app/password-generator/lib.ts). With all four sets switched on, the pool holds 89 characters and each one contributes about 6.48 bits, since a single character is a choice among 89 equally likely options and log₂ 89 ≈ 6.48. The arithmetic also runs in reverse: a reading of 51.8 bits means the search space contains 2 to the power of 51.8 distinct passwords, and each extra bit doubles what an attacker must try.

The table below was generated by running the tool's own formula over its full 89-character pool. The crack-time column assumes an offline attacker testing 10¹¹ — one hundred billion — guesses per second, the harsh end of plausible attack hardware; the next section unpacks that assumption.

The colored label under the result maps onto the same scale in steps: below 28 bits reads Weak, below 60 Medium, below 80 Strong, and from 80 upward Very Strong. The meter underneath fills along it too — the score divides the entropy by 128 bits and rounds, which is why a 16-character draw at 103.6 bits sits 81 percent along the bar. Eighty is the line worth remembering, because past it the crack times stop being years anyone can count: reaching it takes 13 characters from the full pool, since the exact crossing sits at 12.35 characters and the tool cannot cut a character in half.

Every toggle edits the pool, and the per-character yield follows it. Excluding look-alike characters — 0, O, o, 1, l, I, L — trims the pool from 89 to 82 and costs about 0.12 bits per character, so a 16-character password drops from 103.6 to 101.7 bits. Turning symbols off as well leaves 62 characters worth 5.95 bits each, and that is where the widely quoted '16 characters ≈ 95 bits' figure comes from: it describes a letters-and-digits password, not this tool's full-pool default.

Every crack-time figure depends on an attack model, so here it is spelled out. The 10¹¹ guesses per second in the table describes an offline attack: someone has obtained a copy of a password database and tests candidates against the hashes on their own hardware, where nothing throttles them. A rig of modern graphics cards facing passwords stored under an antiquated hash reaches roughly that pace. Against a deliberately slow hash such as bcrypt, the same hardware manages tens of thousands of guesses per second, and each thousandfold slowdown stretches the table's times by a factor of a thousand. The table quotes the harsh end on purpose, because planning numbers should survive the weakest storage you might encounter rather than assume the strongest.

Eighty bits is a sensible floor for accounts whose loss would genuinely hurt: your email first, since password resets for everything else hang off it, then banking and any account holding payment details. With the full pool that takes 13 characters; the tool's 16-character default clears it with room to spare, and 20 characters at 129.5 bits is beyond any brute force that exists. Pushing the slider to its maximum of 128 yields 828.9 bits — a number with no remaining adversary — and length past roughly 20 adds nothing an attacker could feel, while some sites cap accepted lengths below even that.

Length beats complexity because of how the arithmetic compounds. Each added character multiplies the search space by the whole pool; each added character class enlarges the pool once. A 12-character draw from the lowercase-only pool carries 56.4 bits, while 17 lowercase letters reach 79.9 — above the 77.7 that a 12-character draw from the full pool carries. Site rules that demand symbols without permitting length work against themselves, because humans answer predictable requirements with predictable substitutions (Password1! and its relatives), and those sit at the top of every attacker's list. Where the length is yours to choose, spend the budget there.

The entropy arithmetic is only meaningful if every character in the pool is equally likely to appear, and that is what crypto.getRandomValues provides. The generator calls it directly (the cryptoRandom helper in the lib), drawing unsigned 32-bit integers from the browser's cryptographically secure source. The everyday alternative, Math.random, is a seeded pseudo-random generator built for games and simulations: its sequence is fully determined by internal state, and enough observed outputs can reveal that state along with everything after it. A password built on Math.random looks random while actually exploring a search space the size of the generator's state, not the 89-character pool the entropy number promises.

Two details of the lib shape what you get. buildPool both concatenates the enabled sets into one pool and keeps them aside as a guaranteed list; generatePassword draws one character from each enabled set first, fills the remaining positions from the combined pool, then runs a Fisher–Yates shuffle with the same cryptographic source, so a guaranteed character is never findable by position. The requested length is honored with one guard: it can never fall below the number of enabled classes. One mechanical wrinkle gets named here because security prose usually skips it — random integers are folded onto pool positions by remainder, and since 89 does not divide 2³² evenly, 45 of the 89 possible remainders receive one draw more per batch of 4,294,967,296 than the other 44. The tilt on the characters they land on is about two parts in a hundred million: real, measurable, and dwarfed by the unevenness of any password a human picks.

Nothing about the draw leaves your machine. Generation happens in the page; no request is issued and no value is transmitted. The one record kept on your own device is a history of the last five results, stored in the browser's local storage. That history is convenient across visits and worth remembering when a computer is shared, since anyone opening this page on the same browser profile can read it. Clearing the browser's site data removes it.

A generated password protects exactly one account well. Reuse is the failure that turns a single breach into many: attackers take leaked email-and-password pairs and replay them against other services, which is why a password shared between two accounts defends neither. When a service you use reports a breach, treat that account's password as spent and generate a replacement rather than editing the old one — flipping a trailing character preserves every structural habit the leaked copy already taught an attacker.

• Keep them in a password manager: an encrypted vault unlocked by one long passphrase you can actually remember.
• Make each account's password unique — generate a fresh one per signup instead of varying an old favorite.
• Turn on two-factor authentication wherever it exists, so a stolen password alone opens nothing.
• Never relay one through chat or email; use the manager's own sharing feature when a credential must be handed over.
• Generate again after a password has been visible on screen during a share or a recording.

Two-factor authentication is a second axis rather than a thicker lock: it adds a proof — a device, an app code, a hardware key — that does not travel with the password, so stealing one factor no longer admits anyone. The generator's part in this picture is scope and honesty: any length from 4 to 128, any mix of the four classes, and the exact bit count printed under every result, so the trade you are making is one you can see and re-derive yourself.