Built on crypto.getRandomValues rather than Math.random, and generated entirely on your device. Nothing you see here is ever transmitted.
The strength of a random password is the size of its character pool raised to the power of its length. Because length sits in the exponent and the pool sits in the base, adding characters buys far more than adding character types. The arithmetic is worth seeing rather than taking on faith.
A pool of 26 lowercase letters at 16 characters gives 26^16, roughly 4.4 x 10^22 combinations. A pool of 95 printable ASCII characters at 8 characters gives 95^8, roughly 6.6 x 10^15. The lowercase-only password is over six million times larger despite using the simplest possible alphabet. This is why the password length field is the first control on this page and why the default is sixteen rather than the eight that older rules assumed.
The usual objection is that attackers know you are using lowercase and will target that pool. They will, and it does not rescue the shorter password. The comparison above already assumes the attacker knows both pools exactly. Kerckhoffs's principle applies here: assume the attacker knows the system, and let the entropy do the work.
Entropy is the honest unit. Each character drawn uniformly from a pool of size N contributes log2(N) bits. Lowercase alone is 4.7 bits per character, so sixteen characters is about 75 bits. The full 95-character set is 6.55 bits per character, so sixteen characters is about 105 bits. Both are far beyond what offline cracking reaches today; the eight-character version at 52 bits is not.
This generator uses crypto.getRandomValues, the browser's cryptographically secure random source. It does not use Math.random. That distinction is the whole game and it is invisible in the output. Two strings can look equally scrambled while one is trivially predictable.
Math.random is a fast pseudorandom generator built for simulations and shuffling. In V8 it uses xorshift128+, seeded once per context. It is not designed to resist analysis, and it does not: given a modest run of consecutive outputs, the internal state can be recovered and every subsequent value predicted. That is fine for dealing a hand of cards and disqualifying for anything protecting an account.
crypto.getRandomValues draws from the operating system's entropy pool (/dev/urandom on Unix-like systems, BCryptGenRandom on Windows) which is seeded from hardware sources and designed so that observing past output tells you nothing about future output. Every browser in current use implements it.
There is a second, quieter property that matters as much: modulo bias. Mapping a random byte onto a 95-character alphabet with a naive remainder makes the first few characters of the alphabet slightly more likely, because 256 does not divide evenly by 95. The skew is small but it is real, it is systematic, and it shrinks the effective keyspace. This generator draws from a 32-bit range where the bias is negligible against the pool sizes on offer.
Generation happens entirely on your device. No password shown here is transmitted, logged or stored. Closing the tab destroys them, which is also why you should paste what you generate into a manager before you navigate away.
The four toggles decide the pool, and their effect is smaller than most password rules imply. Turning on symbols raises per-character entropy from 5.95 bits (letters and digits) to 6.55 bits. Over sixteen characters that is about ten extra bits, real, but less than adding two more characters, and it costs you every time you type the password on a phone keyboard.
Enable symbols when a site demands them, which many still do. Composition rules of that kind are widely considered counterproductive by modern guidance precisely because they push people toward predictable substitutions (the capital at the front, the digit and exclamation mark at the end) rather than toward length. NIST's own guidance now advises against mandating them.
Skip look-alikes removes l, I, 1, O, 0 and o. Use it for any password a human will read from a screen and retype elsewhere: a Wi-Fi key on a printed card, a temporary credential read aloud, a device set up by someone else. The cost is about 0.1 bits per character, which is nothing against the confusion it prevents. Leave it off for a password going straight into a manager, where nobody will ever read it.
The count field generates a batch. Generating several and choosing one does not weaken them, each is drawn independently, and it is useful when you are setting up multiple accounts in one sitting.
A passphrase of five or six random words from a large list is the better choice for the handful of secrets you must type from memory: your device login, your password manager's master password, your disk encryption. Six words drawn from a 7,776-word list carry about 77 bits, comparable to a strong random password, and are far easier to retype without error.
The critical word is random. A phrase you invented is not a passphrase, because you did not sample it uniformly. You chose it, and human choice is heavily skewed toward memorable structures that cracking tools model well. Song lyrics, quotations and film titles are in the wordlists attackers use.
For everything else, the honest answer is that you should not be memorising passwords at all. Use a password manager, let it generate a distinct sixteen-plus character password per site, and never see most of them. The dominant real-world attack is not brute force against a strong password; it is credential stuffing, reusing a password that leaked from a breach elsewhere. Uniqueness per site defeats it completely, and uniqueness is only practical with a manager.
And enable multi-factor authentication where it is offered. A second factor protects the account even when the password is compromised, which is the scenario worth planning for.
It does not check your password against breach corpora. Doing so would mean sending it, or a hash prefix of it, somewhere, and this page has no backend by design. Have I Been Pwned's range API is a well-designed way to do that check with k-anonymity, and it is the right tool if you want it, but it belongs on a page that is honest about making a network request.
It does not score strength with a meter. Strength meters mostly estimate what a human chose; for a uniformly random string the strength is already known exactly from the pool size and the length, and a meter would add theatre rather than information.
It does not remember anything. There is no history, no favourites, no localStorage entry for generated passwords, deliberately. A convenience feature there would leave secrets on disk in a browser profile that may be shared or backed up.
No. They are generated in your browser using its own crypto.getRandomValues API. Nothing is transmitted, logged or stored, there is no backend to receive them, and closing the tab discards them, so paste what you need into a manager first.
Sixteen characters is a sound default and the one this page starts on. Below twelve you are inside the range that well-funded offline attacks reach against fast hashes; above twenty the extra entropy stops being the weakest part of your security.
Only if the site requires them. Symbols add roughly 0.6 bits per character, so adding two characters of length beats adding the whole symbol set, and a symbol-free password is far easier to type on a phone.
Because they are hard to tell apart in most fonts. It matters only for a password a person will read and retype, a Wi-Fi card, a handover. For one going straight into a password manager, leave them in and keep the larger pool.
For the few secrets you type from memory, yes, six randomly chosen words are about as strong as a strong random password and much easier to retype. It must be randomly chosen, though; a phrase you thought of yourself is not a passphrase in the security sense.
In principle, with probability so small it is not worth planning around: at sixteen characters from a 95-character pool there are about 4 x 10^31 possibilities. Each generation is independent, so there is no sequence an observer could follow.
Because its output is predictable. V8's implementation is seeded once and its internal state can be recovered from a short run of outputs, after which every future value is known. That is acceptable for shuffling a list and disqualifying for credential generation.