HomeText & GeneratorsPassword Generator

strong passwords. one click.

generate cryptographically secure passwords with customizable length and character sets. runs entirely in your browser.

xG)lhDN4h@@:2|9C
Strengthvery strong
16
8128

The math, in one paragraph

A random password's strength is its entropy: how many possible passwords could have come out of the same generator. The formula is log2(alphabet_size ^ length) bits. A 16-character password drawn from a 94-character ASCII alphabet carries log2(94 ^ 16) ≈ 105 bitsof entropy. To put that in scale: at one trillion guesses per second, exhausting 105 bits of entropy would take about a billion times the current age of the universe. Anything past ~80 bits is “will not be brute-forced in any practical scenario.” This generator defaults to settings well above that threshold.

The character classes that matter

Most password forms ask you to mix lowercase, uppercase, numbers, and symbols. The reason is not that the password becomes meaningfully harder to guess — it is that the form was designed to enforce minimum complexity for users who would otherwise pick password123. For a randomly generated password, the alphabet you draw from is what controls entropy, and bigger is better.

  • Lowercase only (26 chars) — 4.7 bits per character. A 16-char password gets you 75 bits.
  • Lowercase + uppercase (52 chars) — 5.7 bits per character. 16 chars = 91 bits.
  • Letters + digits (62 chars) — 5.95 bits per character. 16 chars = 95 bits.
  • Letters + digits + symbols (~94 chars) — 6.55 bits per character. 16 chars = 105 bits.

Doubling the alphabet size adds one bit of entropy per character. Doubling the length adds one bit per each existing character. Length is the more powerful lever.

The “include symbols” trap

Including symbols in a password feels safer, and it is — until you paste the password into a system that silently rejects some of them. Common offenders:

  • Email systems that strip semicolons, quotes, or backticks from the password field on submit.
  • Mobile apps that present a different keyboard for password fields, hiding less-common symbols on a deeper page.
  • Old systems that limit passwords to a subset of ASCII or to a maximum length.
  • Shell scripts that pass the password as a command-line argument, where a stray $ or ! gets interpreted before reaching the target.

Practical answer: include symbols when generating, but exclude the truly hostile ones (`, $, ", ') when you suspect the downstream system is touchy. If a paste-test fails, regenerate with a tighter symbol set rather than typing around the problem.

Where the randomness comes from

The generator uses crypto.getRandomValues(), the cryptographic random number generator built into every modern browser. That is the same source recommended by the WebCrypto spec, sourced from your operating system's entropy pool (which itself draws from hardware noise, interrupt timing, and other unpredictable sources).

typescript
function pickChar(alphabet: string): string {
  const buf = new Uint32Array(1);
  crypto.getRandomValues(buf);
  return alphabet[buf[0] % alphabet.length];
}

Critically, the generator does not use Math.random(), which is not cryptographically secure and is famously predictable enough for an attacker who can observe a few outputs to predict future ones. If you have ever copied a password generator from Stack Overflow that uses Math.random(), throw out anything you generated with it.

A note on modulo bias

The naive random_int % alphabet_length approach has a small statistical bias toward the early characters in the alphabet when the random range is not an exact multiple of the alphabet size. For 32-bit random ints and 94-char alphabets, the bias is on the order of 10−9 per character — practically negligible for password use. We use that simple approach because correcting it would not change any password by even one bit of effective entropy.

Length recommendations for 2026

  • 16 characters with a full alphabet — the minimum we would suggest for any account. ~105 bits of entropy. Comfortable margin against any brute-force attack that does not have access to a working quantum computer of a kind that does not exist yet.
  • 20 characters — for high-value accounts (email, banking, identity provider). The extra characters push entropy past 130 bits, which is far past the point of being relevant — it is mostly future-proofing.
  • 32+ characters — for service-account credentials, API keys, and other passwords that get stored in config files and never typed by hand. Length is free if you are not typing the password.

Storage is the real problem

A 105-bit password is uncrackable. The actual reason your password gets compromised is almost never brute force — it is a database breach at the service you used the password on, followed by credential stuffing at every other service. Generating a strong password is necessary but not sufficient. The matching practice is using a unique password per service, which means using a password manager.

If you are not using one, fix that first. The best generator in the world cannot save you from reusing a strong password across 40 sites, one of which will eventually leak it.

Privacy of this tool

Passwords are generated entirely in your browser. Nothing is sent over the network, nothing is logged, and nothing is stored on Persimmon's side. Closing the tab is the same as deleting the password from our awareness — we never had it.

The math, in one paragraph

A random password's strength is its entropy: how many possible passwords could have come out of the same generator. The formula is log2(alphabet_size ^ length) bits. A 16-character password drawn from a 94-character ASCII alphabet carries log2(94 ^ 16) ≈ 105 bitsof entropy. To put that in scale: at one trillion guesses per second, exhausting 105 bits of entropy would take about a billion times the current age of the universe. Anything past ~80 bits is “will not be brute-forced in any practical scenario.” This generator defaults to settings well above that threshold.

The character classes that matter

Most password forms ask you to mix lowercase, uppercase, numbers, and symbols. The reason is not that the password becomes meaningfully harder to guess — it is that the form was designed to enforce minimum complexity for users who would otherwise pick password123. For a randomly generated password, the alphabet you draw from is what controls entropy, and bigger is better.

  • Lowercase only (26 chars) — 4.7 bits per character. A 16-char password gets you 75 bits.
  • Lowercase + uppercase (52 chars) — 5.7 bits per character. 16 chars = 91 bits.
  • Letters + digits (62 chars) — 5.95 bits per character. 16 chars = 95 bits.
  • Letters + digits + symbols (~94 chars) — 6.55 bits per character. 16 chars = 105 bits.

Doubling the alphabet size adds one bit of entropy per character. Doubling the length adds one bit per each existing character. Length is the more powerful lever.

The “include symbols” trap

Including symbols in a password feels safer, and it is — until you paste the password into a system that silently rejects some of them. Common offenders:

  • Email systems that strip semicolons, quotes, or backticks from the password field on submit.
  • Mobile apps that present a different keyboard for password fields, hiding less-common symbols on a deeper page.
  • Old systems that limit passwords to a subset of ASCII or to a maximum length.
  • Shell scripts that pass the password as a command-line argument, where a stray $ or ! gets interpreted before reaching the target.

Practical answer: include symbols when generating, but exclude the truly hostile ones (`, $, ", ') when you suspect the downstream system is touchy. If a paste-test fails, regenerate with a tighter symbol set rather than typing around the problem.

Where the randomness comes from

The generator uses crypto.getRandomValues(), the cryptographic random number generator built into every modern browser. That is the same source recommended by the WebCrypto spec, sourced from your operating system's entropy pool (which itself draws from hardware noise, interrupt timing, and other unpredictable sources).

typescript
function pickChar(alphabet: string): string {
  const buf = new Uint32Array(1);
  crypto.getRandomValues(buf);
  return alphabet[buf[0] % alphabet.length];
}

Critically, the generator does not use Math.random(), which is not cryptographically secure and is famously predictable enough for an attacker who can observe a few outputs to predict future ones. If you have ever copied a password generator from Stack Overflow that uses Math.random(), throw out anything you generated with it.

A note on modulo bias

The naive random_int % alphabet_length approach has a small statistical bias toward the early characters in the alphabet when the random range is not an exact multiple of the alphabet size. For 32-bit random ints and 94-char alphabets, the bias is on the order of 10−9 per character — practically negligible for password use. We use that simple approach because correcting it would not change any password by even one bit of effective entropy.

Length recommendations for 2026

  • 16 characters with a full alphabet — the minimum we would suggest for any account. ~105 bits of entropy. Comfortable margin against any brute-force attack that does not have access to a working quantum computer of a kind that does not exist yet.
  • 20 characters — for high-value accounts (email, banking, identity provider). The extra characters push entropy past 130 bits, which is far past the point of being relevant — it is mostly future-proofing.
  • 32+ characters — for service-account credentials, API keys, and other passwords that get stored in config files and never typed by hand. Length is free if you are not typing the password.

Storage is the real problem

A 105-bit password is uncrackable. The actual reason your password gets compromised is almost never brute force — it is a database breach at the service you used the password on, followed by credential stuffing at every other service. Generating a strong password is necessary but not sufficient. The matching practice is using a unique password per service, which means using a password manager.

If you are not using one, fix that first. The best generator in the world cannot save you from reusing a strong password across 40 sites, one of which will eventually leak it.

Privacy of this tool

Passwords are generated entirely in your browser. Nothing is sent over the network, nothing is logged, and nothing is stored on Persimmon's side. Closing the tab is the same as deleting the password from our awareness — we never had it.

more free tools

PDF utilities, image tools, developer helpers — all free, no signup.

Something wrong?