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: ` !@#$%^&*()_+~|}{[]:;?><,./-= `. It deliberately excludes the single quote ', double quote ", backslash \, and space — the characters most likely to break shell commands, YAML, JSON, and .env parsers. It does include shell-active characters like $, backtick, !, &, ;, and |`, so quote the value in shell contexts, 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.