Why this generator runs entirely in your browser
Every password generator asks you to trust it. Most deserve a little less of that trust than they let on. This one is built so you do not have to extend any.
Think about what happens when you generate a password on a typical website. You click a button, the site produces a strong-looking password, you copy it, you move on. Somewhere in there, a question went unasked: where did that password get made, and who else saw it on the way to you?
For a lot of online generators, the honest answer is that the password was built on their server and sent across the internet to your screen. Which means, for a moment, your brand-new password existed on a machine you do not control, traveled over a network, and arrived in your browser. The site will tell you it does not keep a copy. Maybe it does not. You have no way to know, and that is the whole problem.
What does it mean for a password tool to "phone home"?
A tool phones home when it sends something about you somewhere else. For a password generator, the thing it could send is the worst possible thing to send: the password itself. A server-side generator has to, by definition, because the password is made on the server and delivered to you. Even a generator that runs in your browser can phone home if it quietly transmits what it produced for analytics, logging, or "telemetry."
A password generator that phones home is a contradiction. The entire point of the tool is to produce a secret. The moment that secret leaves the device it was made on, it is no longer entirely yours, and you are back to trusting that everyone who could have seen it chose not to look. The best way to keep a secret is to not hand it to anyone, including the tool that made it.
How does running in the browser fix that?
When generation happens entirely in your browser, the password is created on your machine, displayed on your machine, and never sent anywhere. There is no server that built it, so there is no server that could log it. There is nothing in transit to intercept. The question "who else saw my password" has a clean answer for once: nobody, because it never went anywhere.
This is a different kind of guarantee than a privacy policy. A privacy policy is a promise to behave. Client-side generation is an arrangement where there is nothing to behave about, because the sensitive thing never reaches anyone who would have to be trusted. Promises can be broken, quietly, and you would never find out. An architecture that never receives your password cannot leak what it does not have.
What "client-side via the Web Crypto API" actually means
Modern browsers ship with a built-in cryptography toolkit called the Web Crypto API. It runs locally, as part of the browser itself, with no network involved. When a generator uses it, the random values that become your password are produced on your device by the browser's own vetted cryptographic code.
"Client-side" means every step happens in the page running on your machine: gathering randomness, assembling the password, measuring its strength, showing it to you. No request is made to build it, and none is made to report it. You can confirm this yourself by opening your browser's developer tools, watching the network tab, and generating a password. Nothing goes out. That is the difference between a claim you read and a fact you can check.
Is randomness in the browser actually any good?
It is, as long as the tool uses the right source. There are two ways to get random numbers in a browser, and only one of them is fit to make a password from. The wrong one is the convenient general-purpose randomness most code reaches for. The right one is the cryptographic randomness built for exactly this. The gap between them is the difference between a password an attacker cannot predict and one they sometimes can.
A serious generator uses the cryptographic source, and it uses it carefully, because even a good source can be skewed if you draw from it the lazy way. Getting this right is unglamorous and it matters more than almost anything else the tool does, because all the entropy math in the world means nothing if the randomness underneath it is predictable.
Why getRandomValues with rejection sampling, and never Math.random
Math.random() is a pseudo-random generator built for speed, not secrecy. Its output comes from an internal state that can be reconstructed from a handful of observed values, after which every future "random" number is predictable. It is also seedable and not guaranteed uniform across implementations. For anything an attacker would want to guess, it is disqualifying.
crypto.getRandomValues() draws from the operating system's cryptographically secure random source, the same class of randomness used for encryption keys. Its output cannot be predicted from past output.
There is one more trap. To turn a random number into, say, a character from a 70-symbol alphabet, the naive move is random % 70. But unless the random range is an exact multiple of 70, the low-numbered characters come up slightly more often, a skew called modulo bias. A careful generator avoids it with rejection sampling: it discards the few random values that fall in the uneven tail and draws again, so every character is exactly equally likely. The result is uniform, unbiased, and unpredictable, which is the only kind of randomness a password should be made of.
If nothing is sent, why does the breach checker touch the network?
One feature does reach out, and I will not pretend otherwise. Checking a password against known breaches requires comparing it to a list that lives elsewhere, so that single feature makes a network request. It is the one deliberate exception to "nothing leaves the device," and it is built so that the thing leaving is not your password.
The breach check sends only a short fragment of a hash, shared by hundreds of other passwords, and does the actual comparison on your device. Your password and its full fingerprint never go anywhere. So even the one feature that talks to the network was designed around the same principle as the rest of the tool: reveal as little as possible, and never the secret itself. The full mechanics are on the breach-checking page.
Why does an open, auditable build matter?
Because "trust me" is not a security model, and "check for yourself" is. When the code that runs in your browser is open and inspectable, the claims on this page stop being claims. Anyone can read what the tool does, watch the network to confirm it does nothing more, and verify that the password really is made and kept locally. The trust does not rest on the operator being honest. It rests on the behavior being visible.
That is the through-line behind every choice here. Generate on the device. Send nothing. Make the one necessary network call reveal nothing useful. Lock the whole thing down with a policy the browser enforces, and leave the code open so none of it has to be taken on faith. A password tool should be the one place on the internet that does not ask you to trust it. It should simply be unable to betray you.
Generate a password, privately
Common questions
Is it safe to generate passwords online?
It depends entirely on where the password is made. A tool that generates the password on its server and sends it to you exposes it to that server and the network. A tool that generates entirely in your browser never transmits the password at all, which is far safer. Check whether the generator runs client-side.
What does client-side password generation mean?
It means the password is created on your own device, by code running in your browser, and is never sent to a server. There is nothing to log and nothing in transit, so the password stays on your machine unless you choose to save or paste it elsewhere.
Can I verify that my password is not being sent anywhere?
Yes. Open your browser's developer tools, go to the network tab, and generate a password. If the tool is genuinely client-side, you will see no outgoing request when generating. With an open, auditable build you can also read the code itself.
Is browser randomness secure enough for passwords?
Yes, when the tool uses the browser's cryptographic random source (crypto.getRandomValues) rather than the general-purpose Math.random. The cryptographic source is the same class of randomness used for encryption keys and cannot be predicted from its past output.
Why does the breach checker connect to the internet if nothing else does?
Because comparing your password against a breach list requires data that lives elsewhere. It is the one deliberate network feature, and it is built with k-anonymity so only a short hash fragment is sent, never your password. A strict Content Security Policy limits the page to that single endpoint.