Length beats complexity — the math and the policy
NIST’s modern guidance (SP 800-63B) dropped the old rituals: no mandatory symbol classes, no periodic forced rotation. The reasoning is arithmetic — Tr0ub4dor&3-style substitutions add almost nothing against cracking tools that try them first, while every additional random character multiplies the search space by the full alphabet. When a site forces composition rules, satisfy them with the checkboxes here, but get your real security from setting the length slider to 16+.
One password, one site — why reuse is the actual risk
Most account takeovers don’t crack anything: they replay credentials leaked from one breached site against hundreds of others (credential stuffing). A password’s strength is irrelevant if it’s shared across services. The working setup: a password manager storing a unique generated password per site, protected by one strong memorized passphrase, plus two-factor authentication on the accounts that matter (email first — it’s the reset key to everything else).
Where generated passwords should and shouldn’t go
Generated passwords belong in a manager, not in your memory, a notes app, or a spreadsheet. Two exceptions deserve passphrases instead of random strings: the master password itself, and disk-encryption or OS login passwords you must type before any manager is available. For those, generate a 5–6 word passphrase and practice it for a week — memorability under stress is part of the spec.
A note on the strength meter
The meter here scores raw entropy from length and active character sets. It cannot know whether a string is meaningful — correcthorse typed by hand scores like random lowercase but sits in every cracking wordlist. Trust the meter only for passwords this tool generated; for human-invented passwords, assume the real strength is far lower than displayed.