Advanced Password Generator

Overview

A password you did not choose

Direct answer: This password generator makes a random password or passphrase in your browser using crypto.getRandomValues, the same randomness a browser uses for cryptography — never Math.random. Set the length and the character sets, or switch to a passphrase of real words, and it tells you the entropy in bits and how long the result would stand up to offline cracking. Nothing is generated on a server, nothing is sent anywhere, and nothing is stored.

The reason to use a generator at all is that people are bad at being random and good at believing they are. A password you invented has structure — a word, a date, a substitution you thought was clever — and structure is exactly what a cracking rig searches first. A generated password has none, which is what makes the bit count below it mean something.

The Advanced Password Generator in dark mode: a Password and Passphrase segment with a length slider set to sixteen, four character-set switches and two rule switches in the cyan Settings pane, a sixteen-character random password in the magenta result pane, and a stat line reading Very strong, entropy 104 bits — Cyan is what you asked for, magenta is what it made — and the bit count is the honest one

The entropy figure is a count, not a score. Plenty of strength meters guess at how hard a password looks; this one knows exactly how many choices went into the secret, because it made every one of them. Sixteen characters from the full 91-character pool is 16 × log₂(91) ≈ 104 bits. Turn a character set off and the number falls. Turn on no character twice in a row and it falls by a fraction, because that rule really does remove one option from every position after the first — and the figure accounts for it rather than ignoring it.

The passphrase list is 1,947 words, at 10.93 bits each, drawn from common English and filtered so that no two words share their first three letters — so a typo at the start cannot silently land you on a different word. Six words is 66 bits and reads back over a phone without spelling anything out. Capitalising the words is offered because some password rules demand it, and it is labelled as adding no entropy, because capitalising all of them is a formatting choice rather than a random one.

Related: the Hash Generator for checksums, the UUID Generator for identifiers, and the HMAC Generator for signing.

Guide

How to use the password generator

Choose a mode

A password is a string of random characters: the densest secret per keystroke, and the right shape for something a password manager will hold. A passphrase is a run of random words: far easier to read aloud, retype on a phone or copy off a screen, at the cost of being longer. Both are generated the same way, from the same source of randomness.

The generator in passphrase mode: a Words slider set to six in the toolbar, separator and rule switches in the cyan Settings pane, a six-word hyphenated passphrase in the magenta result pane, and a stat line reading Strong, entropy 66 bits, offline cracking years — Passphrase mode — six words from a 1,947-word list is 66 bits

Set the length

The slider is the single biggest lever you have. Each extra character multiplies the search space by the size of the character pool, so length buys entropy faster than any option below it. Sixteen characters from the full pool is 104 bits; twenty is 130. For a passphrase the slider counts words instead, and six is 66 bits.

Pick your character sets

Four switches: lowercase, uppercase, numbers, symbols. Turning one off shrinks the pool and lowers the entropy, and the figure below the panes moves as you do it. Exclude look-alikes drops the characters that get misread off a screen or misheard over a phone — l I 1 O 0 and the bracket family. No character twice in a row stops immediate repeats; it costs a fraction of a bit per character and the entropy figure accounts for it exactly.

Read the entropy in bits

The stat line is the point of the tool. Entropy is how many bits of genuine randomness the secret carries, and offline cracking turns that into time at 100 billion guesses a second — the rate a rented GPU cluster reaches against a fast hash. Under 40 bits is weak, 60 is fair, 80 and up is durable. Nothing here is an estimate of "how hard your password looks"; it is a count of the choices that were actually made.

Switch to bulk if you need many

Open Generate a batch for up to 500 at once, each one generated independently with the settings above, then download them as a .txt. The file is assembled in your browser and saved by your browser; nothing is uploaded.

The Generate a batch drawer open below the tool, showing a quantity field set to ten and a textarea holding ten separately generated passwords — A batch is 500 independent draws, not one secret repeated

Copy or download

Copy puts the secret on your clipboard. Paste it straight into your password manager rather than into a document, a chat, or a ticket — the clipboard is the shortest path between this page and the place the secret belongs. Nothing generated here is stored, logged or sent anywhere, and once the page has loaded it all works offline.

Support

Frequently Asked Questions

How many bits of entropy does a secret actually need?

It depends on the value and lifetime. As a practical guide: ≥ 128 bits for long-lived, high-value secrets like a JWT/HS256 signing key or an API key, and ≥ 80 bits for lower-value or short-lived ones. With the full 91-character pool (6.51 bits/char), a 20-character secret already exceeds 128 bits. More length is cheap here, so when in doubt, add characters.

How is password entropy calculated?

For a randomly generated password, entropy in bits is length × log₂(charset size). So 16 characters from a 91-character pool is 16 × log₂(91) ≈ 16 × 6.51 ≈ 104 bits. Each added character adds a fixed number of bits; each larger character set raises the per-character value. The formula assumes each character is chosen independently and uniformly at random — which this tool does.

Is this cryptographically secure — what RNG does it use?

Yes. Character selection uses window.crypto.getRandomValues (the Web Crypto CSPRNG), not Math.random, and it applies modulo-bias rejection sampling so every character is uniformly distributed rather than merely random-looking. Both password characters and passphrase words go through the same secure function. You can verify there's no Math.random in the page source. That's what makes the entropy figures meaningful rather than optimistic.

Does the generated secret ever leave my browser?

No. Generation, the entropy maths, and the bulk .txt blob all run locally in your browser; there's no fetch, FormData, or XMLHttpRequest carrying secret material, and it works offline. The page does load Google Analytics for page-level metrics, but it never transmits a generated secret, your settings, or any input — you can confirm this in your browser's network tab. Nothing you generate is stored either.

How do I generate a secret that won't break bash, YAML, or a .env file?

Turn symbols off and use the alphanumeric pool (62 characters, 5.95 bits/char) — still ~95 bits at 16 characters, and safe to paste almost anywhere. Even with symbols on, this tool deliberately omits the single quote, double quote, backslash, and space — the worst quoting hazards. But the symbol set does include shell-active characters, so for an unquoted shell context or a fragile parser, alphanumeric is the safe choice.

How long should a JWT signing secret or API key be?

For an HS256 JWT secret, aim for at least 256 bits of entropy to match the algorithm's strength — about 40 alphanumeric characters, or ~32 characters from the full pool (~208 bits, close enough for most policies; go to 40 for a strict 256-bit target). For API keys, 128 bits (≈ 20 full-pool characters) is a common floor. When in doubt, longer is free here, so over-provision.

Can I generate many secrets at once for seeding an environment?

Yes. Bulk mode generates 2–500 secrets using your current mode and settings, so every item in the batch has the same entropy. The list appears in a text area with a Download .txt button (built locally from a Blob). It's handy for seeding database users across microservices, provisioning test accounts, or rotating a set of credentials. Note there's no duplicate check — at realistic lengths a collision is astronomically unlikely.

Which symbols does this use, and which does it avoid?

The symbol set is 29 characters, and it is !@#$%^&*()_+~`|}{[]:;?><,./-= — it deliberately excludes the single quote, the double quote, the backslash and the space, which are the characters most likely to break shell commands, YAML, JSON and .env parsers. It does include shell-active characters: the dollar sign, the backtick, the exclamation mark, the ampersand, the semicolon and the pipe. Quote the value in a shell, or turn symbols off for a fully alphanumeric, paste-anywhere secret.

How accurate is the "cracking time" estimate?

Treat it as a rough bucket, not a guarantee. It's computed from a single hard-coded model: 2^bits / 1e11, i.e. an offline attacker making 100 billion guesses per second who already knows your character set. Real-world time varies enormously with the attacker's hardware and, crucially, how the secret is stored (a slow KDF makes guessing far harder). The entropy in bits is the reliable number; the time is illustrative.

How strong are the passphrases — how big is the word list?

Be realistic: the built-in list is 90 words at about 6.49 bits per word, so even the 12-word maximum reaches only ~78 bits — below the "very strong" threshold. That's fine for something memorable, but for maximum strength use password mode. For comparison, an EFF Diceware list has 7,776 words (12.9 bits/word). We'd rather state this plainly than overstate passphrase strength.

What does "No Repeated Characters" actually do?

Less than the name suggests: it blocks a character from equaling the one immediately before it, so it prevents adjacent repeats only — aa is blocked, but aXa passes. It doesn't guarantee all-distinct characters, and because it constrains selection slightly, it makes the true entropy a touch lower than the displayed figure (which assumes unconstrained choice). Leave it off unless a specific policy needs no doubled characters.

Where should I store the secret after generating it?

Not on the clipboard for long, and never in Git. Copying places the secret where any app with clipboard access can read it, and a secret pasted into a chat or committed to a repo is compromised regardless of its entropy. Move it straight into a secrets manager or an environment variable, restrict who can read it, and rotate it if it's ever exposed. Entropy protects the secret; your handling protects the entropy.

Still have questions?

If you can't find the answer you're looking for, feel free to contact our support team.

Privacy Focused

Instant Results

No Signup

Browser Based

A password you did not choose

How to use the password generator

Frequently Asked Questions

Still have questions?