What Makes a Password Generator Trustworthy in the Browser?

A password generator should do more than produce strings that look complicated.

A trustworthy one needs a secure source of randomness, clear rules for how characters are selected, honest strength estimates, and a privacy model that does not claim more than the browser can guarantee. It also needs to fit into a wider account-security practice: unique passwords, a password manager, and multi-factor authentication where available.

Here is what I look for when evaluating a browser-based password generator.

Start with the random source

The first question is simple: where do the random characters come from?

Math.random() is fine for UI effects, demos, and many ordinary tasks. It is not a cryptographic random source, so it should not generate passwords.

In a browser, the appropriate API is crypto.getRandomValues(). It fills a typed array with cryptographically strong random values supplied by the browser's Web Crypto implementation. MDN documents the API and its security purpose.

A basic pattern looks like this:

const values = new Uint32Array(1);
crypto.getRandomValues(values);

const randomValue = values[0];

That alone is not the whole implementation, though. The generator still has to turn that random number into a character index correctly.

Avoid modulo bias

Suppose a generator has an alphabet of 94 characters and chooses one with this code:

const index = randomValue % 94;

A 32-bit random value has 2^32 possible outputs. Since 2^32 is not evenly divisible by 94, some character indexes occur slightly more often than others.

The difference is small, but password generation is one of the places where there is no reason to accept it. A better approach uses rejection sampling:

1. Find the largest multiple of the alphabet size that fits inside the random range.
2. Discard values outside that range.
3. Apply modulo only to the remaining values.

That keeps every permitted character equally likely.

Make policy choices explicit

Many sites still require a particular mix of character types. A generator should let you choose among lowercase letters, uppercase letters, digits, and symbols, then make sure the result satisfies the selected policy.

For example, if you enable all four groups, a generated password should contain at least one character from each group. It is not enough to draw from a combined alphabet and hope that every group appears.

There is an important distinction here. NIST advises service operators not to force composition rules such as "one uppercase, one digit, one symbol" on passwords that users create themselves. Those rules often lead to predictable edits. But a generator still needs to meet the rule when a particular service requires it. NIST's current guidance also emphasizes length, allowing long passwords, and avoiding arbitrary periodic password changes.

The practical rule is straightforward: follow the destination site's requirements, then make the password as long as the site accepts.

Length usually buys more than clever punctuation

A random password benefits directly from length. If every position can be chosen from an alphabet of A characters and the password has length L, the simple search space is:

A^L

Its approximate entropy in bits is:

L × log2(A)

Real generators may have extra constraints, such as requiring every selected character group to appear. In that case, an honest estimate should calculate the space of valid strings, not just show a generic score.

Even then, "estimated entropy" is not a promise about account security or a prediction of crack time. It describes the generator's search space under its stated assumptions. Account security also depends on the site's password storage, rate limiting, recovery flow, phishing protections, and whether the password has been reused elsewhere.

Local processing is useful, but it has limits

For sensitive text, browser-only processing is a meaningful design choice. It avoids sending a newly generated password to a remote service just to create it.

I built ToolExo's Password Generator to generate passwords locally with crypto.getRandomValues(). It uses rejection sampling for character selection, supports a length from 8 to 128 characters, and calculates its estimate from the exact set of passwords allowed by the selected rules.

"Local" does not mean the password disappears from every part of your device. The clipboard may be readable by other software. A browser extension, screen recording tool, sync service, or compromised machine changes the threat model. Treat a generated password as sensitive from the moment it appears.

A generator can reduce exposure by hiding the output by default and allowing you to reveal or copy it only when needed. It cannot secure an unsafe endpoint.

Ambiguous characters are a usability trade-off

Characters such as I, l, 1, O, 0, and o are easy to confuse when a password must be read from a screen or typed manually.

Removing them can be sensible for a password that will be entered by hand. The trade-off is a smaller character set, which slightly reduces the number of possible passwords. In most cases, adding a few more characters of length is a better fix than accepting a hard-to-read password.

If a password manager fills the password automatically, ambiguity matters less. If you will type it into a console, device, or recovery screen, it matters more.

A generator is not a password manager

A generator answers one question: "What should this password be?"

A password manager handles the harder operational question: "How do I store a different strong password for every account and retrieve it safely later?"

Unique passwords matter because reused credentials turn one breach into attempts against other services. NIST specifically notes that distinct passwords reduce password-stuffing risk, and its guidance discusses password-manager use. OWASP also recommends allowing password-manager workflows and paste support in login forms.

For an important account, the working setup is usually:

• Generate a long random password.
• Save it in a reputable password manager.
• Use that password for one account only.
• Enable multi-factor authentication when the service offers it.
• Change the password when there is evidence of compromise, not simply because a calendar reminder appeared.

A short checklist

Before trusting a browser password generator, check whether it:

• uses crypto.getRandomValues() or an equivalent cryptographic source;
• maps random values to characters without modulo bias;
• clearly shows which character groups are enabled;
• guarantees the selected groups appear when required;
• treats entropy as an estimate, not a security guarantee;
• keeps generation in the browser when it claims to;
• explains clipboard and device-level limitations;
• helps you create passwords that work with a password manager.

A password generator does not need a dramatic interface or a vague "military grade" claim. It needs sound randomness, clear behavior, and enough honesty for you to understand what it does not protect.