A password manager does not think up a password the way you would. For each character, it asks the operating system for a genuinely random byte, throws away the ones that would tilt the result toward one part of the alphabet, and maps what is left onto the character set you picked. Nothing about the result is optimized to be memorable, pronounceable or free of anything a human would notice as a pattern — memorability is exactly the property good password generation destroys on purpose.
Where does the randomness actually come from?
Not from Math.random(). Every JavaScript engine ships that function, and it is fast, evenly distributed and completely wrong for this job: it is a deterministic algorithm with a small, fixed internal state, and its output was never built to resist someone trying to predict it. V8, the engine behind Chrome and Node, uses an algorithm called xorshift128+, and security researchers have published working methods that reconstruct its entire internal state from a short run of consecutive outputs — after that, every future call is predictable, and so are the ones already made. The V8 team's own engineering blog says plainly not to use it for anything security-sensitive. A password generator built on Math.random() is not really random — it is obscured, which is a different and much weaker thing.
A real generator, including the one on this page, calls crypto.getRandomValues() instead. In a browser that function is backed by the operating system's own cryptographic random source — /dev/urandom on Linux and macOS, BCryptGenRandom on Windows — the same pool of unpredictability the system uses to generate encryption keys and TLS session data. A native password manager's desktop or mobile app calls the equivalent platform API directly instead of going through a browser. Nobody in this chain is inventing randomness; everyone is drawing from the same well the operating system keeps stirred for exactly this purpose.
Why can't a random byte just become a character?
Because a byte holds 256 possible values, and a character set almost never divides evenly into that number. Take this page's default set — lowercase, uppercase, digits and symbols — and it comes to 86 characters. 256 divided by 86 leaves a remainder of 84, so mapping a byte onto a character with a plain modulo would make the first 84 characters in the set turn up very slightly more often than the last two. The bias is small on a single character, but it is real and measurable, and it does not go away as the password gets longer — it just gets harder to notice.
The fix is what cryptographers call rejection sampling: draw a byte, and if it lands in that leftover 84-value range, throw it away and draw another instead of using it. It costs an extra byte from time to time and nothing else, and in exchange every character in the final password really is equally likely, not just approximately so. A generator that skips this step produces passwords that are quietly weaker than their length suggests, in a way no strength meter downstream can ever catch — the meter has no way to see how the characters were chosen, only what they turned out to be.
What does "bits of entropy" mean for a generated password?
For a password a person invented, entropy has to be estimated, because an attacker's real cost depends on how guessable the underlying pattern is — that estimation problem is the whole subject of how long it actually takes to crack a password. For a password drawn uniformly at random, the arithmetic is exact instead of estimated: entropy is the password's length multiplied by the base-2 logarithm of the character set size. Twenty characters from that 86-character set comes to a little over 128 bits, and every one of those bits is doing real work, because no character's value was correlated with any other character in the password.
Why is a password you never type a different security model?
Memorizing a password forces two compromises a generator does not have to make: it has to be short enough to hold in your head, and — because remembering forty different ones is not realistic — it ends up reused across sites. Reuse is what actually empties most accounts, through credential stuffing rather than brute force. A manager that generates and stores the password removes both compromises at once: length stops being a memory tax, and a unique password per site becomes the default instead of an aspiration nobody keeps up.
It also changes what you are defending against day to day. A password manager's autofill checks the exact origin of the page before it types anything in, so a convincing fake login page on a lookalike domain gets nothing from it — a check your own memory cannot perform, because you cannot compare two domain names character by character as reliably as software can. Copy-pasting the password by hand instead of letting autofill do it throws that particular protection away, since a clipboard has no idea which page it is about to be pasted into.
What you gain in return is a single point of failure you did not have before: the vault itself, unlocked by one master password or a device credential, and however it is encrypted before syncing between your devices. That vault is now the thing worth attacking, which is why its master password is one of the very few you should still choose as a long, memorized passphrase rather than a generated string — it is the one password with no vault of its own to hold it. And a vault that derives its encryption key with a fast function instead of a deliberately slow one such as Argon2id has the same weakness a plain hash has for storing any password, which is worth checking before trusting a manager with everything else you own.
What this generator does not do
It generates, and that is all. It keeps no history of what it made, syncs nothing between devices, and fills in no form for you — closing the tab discards the password along with everything else on the page. That is a real limitation next to a full password manager, and it is also the point: nothing here needs to be trusted with your accounts, because it never holds on to them long enough to matter.
The password generator uses exactly the mechanism described above — crypto.getRandomValues() and rejection sampling — and shows the resulting entropy and a live crack time against five attackers as you drag the length slider. Nothing typed or generated there leaves the page.
For the handful of credentials you cannot hand to a manager, like the master password protecting the vault itself, password vs passphrase works through when a memorized passphrase actually beats a random string, and when it does not.
Frequently asked questions
Why is Math.random() unsafe for generating a password?
It is a deterministic algorithm with a small, fixed internal state, and its output was never built to resist prediction. Researchers have published working methods that reconstruct that internal state from a short run of consecutive outputs of V8’s implementation, after which every future call is predictable. A password built from it is only as safe as that state stays secret, which it usually does not.
What is rejection sampling, and why does a password generator need it?
It is the technique of discarding a random byte and drawing another whenever that byte falls in a range that would make some characters slightly more likely than others. A byte has 256 possible values, and a character set rarely divides evenly into 256, so without this step a generator’s output looks random but is measurably skewed toward part of the character set.
Does a generated password protect me from phishing on its own?
Only indirectly, through the manager that stores it. A password manager’s autofill checks the exact domain before typing anything in, so it stays silent on a convincing fake login page — a check your memory cannot perform. Pasting the password in by hand instead of letting autofill do it throws that protection away.
How is the entropy of a generated password calculated?
It is the password’s length multiplied by the base-2 logarithm of the character set size — for example, 20 characters drawn from a set of 86 comes to a little over 128 bits. That figure is exact rather than estimated, because it assumes every character was chosen uniformly at random, which is true only for a password a generator produced, not one a person invented.
Is this tool itself a password manager?
No. It generates a password and shows its entropy and crack time, and nothing it produces is stored, synced or filled into a form automatically. Closing the tab discards the password. You still need an actual password manager to save it, autofill it, and get the domain-matching protection that comes with that.
Last updated September 24, 2026
