Password / Token Generator

Q: Is the randomness truly random?

It uses the browser-native crypto.getRandomValues, backed by the OS cryptographic RNG (like /dev/urandom or BCryptGenRandom), far stronger than a pseudo-random Math.random(). It fits passwords and tokens; the tool writes no custom RNG of its own.

Q: What does entropy mean, and how much is enough?

Entropy measures how hard it is to guess, roughly 2^(entropy) possibilities. Aim for >= 60 bits for a password, >= 80 for high security. Entropy = length x log2(charset size): 16 chars from lower+upper+digit+symbol is about 95 bits, comfortably strong.

Q: Is the generated password safe to use directly?

Generation happens on your machine and never leaves the browser, and is sufficiently random. But it only generates; storage is on you: no screenshots in chat, no plain text in tickets, and use a password manager for anything long-lived. Temporary tokens and one-time recovery codes are a great fit.

Q: Why must not Math.random() build passwords?

Math.random() is deterministic pseudo-random whose seed can be predicted or reconstructed, shrinking the attacker's search space. Passwords and tokens must use a cryptographic RNG (the one this tool uses), or length is meaningless.

Pure frontend · cryptographically secure: generated with the browser-native crypto.getRandomValues, no network, no logging, never leaves your device. Good for ad-hoc strong passwords, API tokens, and one-time recovery codes.

How to use

Pick the charset and length, enter how many to generate, click Generate. The list appears below with a live entropy (bits) readout. Tick "exclude ambiguous" to drop look-alike characters like 0/O, 1/l/I.

Length Count

lowercase a-z uppercase A-Z digits 0-9 symbols !@#$% exclude ambiguous

Why you cannot just make up a password

A password's strength is not how "complex" it looks to you, but its entropy — how many possibilities an attacker must try. A PaSSword2026! looks fancy but is essentially a dictionary word plus a year plus a symbol; a dictionary attack breaks it fast. What actually stops attackers is a long, unpredictable, random character sequence.

That is why this tool insists on a cryptographic RNG: every character is independent of any semantic input you might choose, leaving the attacker with no prior to exploit.

How entropy adds up per charset

Entropy (bits) ≈ length × log2(charset size). Common pools:

lowercase only, 26 chars: about 4.7 bits per character
lower+upper+digit, 62 chars: about 5.95 bits
plus symbols, ~70–80 chars: about 6.3 bits

Example: 16 chars from lower+upper+digit+symbol ≈ 95 bits, well past "strong"; 12 chars same set ≈ 71 bits, also fine. In reverse, 8 digits is only about 26 bits — weak enough to brute-force in minutes. Short numeric codes are only acceptable as one-time and rate-limited, never as a master password.

Traps you must know

Never use Math.random(): it is deterministic pseudo-random whose seed can be predicted or reconstructed, shrinking the attacker's search space. Passwords and tokens must use crypto.getRandomValues; otherwise length is meaningless. This tool uses exactly that, and applies rejection sampling against the charset length to avoid the slight modulo bias.

Excluding ambiguous characters cuts both ways: dropping 0/O/1/l/I reduces manual-copy errors but shrinks the charset and slightly lowers entropy. Worth it for human-read recovery or activation codes; for machine-consumed, never-read API tokens, leaving it on wastes entropy — turn it off.

Generate is not store: this tool only "makes it random enough"; where it lives and who sees it is out of its hands. Do not screenshot the password into a group chat, paste it in plain text into a ticket, or commit it to a repo. For long-lived secrets, use a password manager (it also deduplicates and checks for breaches).

Clipboard copying: clicking copy puts the password in the system clipboard, which some environments sync to the cloud or keep in history. Clear the clipboard afterward, or operate in a trusted environment.

When a password manager beats this tool

To remember dozens or hundreds of passwords long-term: this tool is random every time, not memorable and not replayable, so a manager is required.
To detect breaches / reuse: a manager warns you if a password shows up in known leak databases.
To share secrets in a team: use dedicated secret management (Vault and the like), not a password pasted in chat.

This tool's job is "make one strong random string on the spot" — temporary passwords, API tokens, database initial passwords, one-time recovery codes; precisely those cases.

Generation advice by credential type

Not all "passwords" are equal; tune by purpose:

Master / account password: length first, 16+ chars from lower+upper+digit+symbol. If you cannot remember it, use a manager; do not cram a weak one into your head.
API token / access token: machine-consumed, never read by a human, so turn off "exclude ambiguous" to keep the entropy; 32+ chars, sent over HTTPS with a short expiry.
One-time recovery / activation code: human-read and hand-typed, so turn on "exclude ambiguous" to cut copy errors; group it (e.g. 4-4-4) with hyphens for readability, but hyphens do not count toward entropy.
DB initial password / key seed: inject into config or secret storage right after generation; keep plaintext only in memory, never in logs.

Length vs service type

Use	Suggested length	Charset	Approx entropy
Daily account password	16	lower+upper+digit+symbol	~95 bits
High-security password	20	lower+upper+digit+symbol	~119 bits
API token	32+	lower+upper+digit (symbols optional)	~190 bits
One-time recovery code	12 (3 groups)	ambiguous excluded	~62 bits
Session key seed	32	full set	~190 bits

More random is not automatically better; it is "enough and usable". A recovery code too random is hard to copy; a token too short cannot resist offline brute force. The table above is a safe default.

A generation example

Say you need an API token for a newly connected CI system: pick length 36, charset lower+upper+digit (ambiguous not excluded), and generate something like kP9mQx2vL8nR4tB7wC3yZ1aE6uH5sJ0dF. Its entropy is about 36 × 6.0 ≈ 216 bits, which offline brute force cannot realistically touch for the foreseeable future. After generating, distribute through secret management, clear the local clipboard when done, and keep it out of any chat log or code repo.

Common credential-management mistakes

Hardcoded in the repo: secrets in source are the number-one leak source; isolate with .env plus secret management (Vault) and scan the repo for leaks.
Plaintext in logs: an app that logs the request body or token verbatim loses everything the moment logs leak. Log scrubbing and regex masking are basic hygiene.
Shared accounts, no rotation: one password for many people, never rotated, so leaving does not revoke access. Issue per-person tokens with expiry and revocability instead.
Length without randomness: stretching "12345678" into "1234567890123456" has the length but near-zero entropy, predictable digit by digit. The random source is what matters, and that is exactly what this tool fixes.

At the end of the day, password strength equals random-source quality times length times charset; this tool gets the random source right, and the table covers the other two.

Bastion host and jump server — strong passwords and key management at the ops entry point
DevSecOps security baseline — password policy, key rotation, leak prevention
Self-hosting with Cloudflare tunnel — credential issuance and protection for self-hosted services