Password & Random Token Generator
Strong passwords and secure tokens from your browser crypto RNG. Nothing leaves your machine.
What this tool does
Creates strong random passwords and random tokens without sending anything anywhere.
In password mode you choose a length from 8 to 128 characters, pick which character
sets to draw from (uppercase, lowercase, digits, symbols), and optionally exclude the
look-alike characters O, 0, l, 1, and I. In token mode you generate 16, 32, or 64
random bytes encoded as hexadecimal or URL-safe base64. All randomness comes from
crypto.getRandomValues, the browser cryptographically secure random
number generator. Runs entirely in your browser. Verify it yourself: open developer
tools, switch to the Network tab, and click Generate. Zero requests, nothing transmitted.
How to use it
For a password, keep the Password mode selected, set a length, tick
the character sets you want, then click Generate. The strength readout
shows entropy in bits, computed as length times log2(pool size), with a plain label
from weak to very strong. Choose 1, 5, or 10 to produce a batch, then use
Copy all to copy the whole list. For a token, switch to
Random token, pick a byte count and an encoding, and generate. A
32-byte hex token looks like 9f86d081884c7d659a2feaa0c55ad0... and carries
256 bits of entropy.
Common use cases
- Account passwords you will store in a password manager.
- Human-readable passwords for a printout or a read-aloud handoff (exclude ambiguous characters).
- API keys, session identifiers, and password reset tokens (32 bytes or more).
- URL-safe secret query parameters and signed link nonces (base64url).
- Seed values, salts, and one-off credentials for local development and tests.
Common pitfalls
- Length beats symbol soup. Adding length raises entropy faster than cramming in exotic symbols. A long password from a modest pool is both stronger and easier to handle than a short dense one.
- Excluding characters lowers entropy. Turning off symbols or removing ambiguous characters shrinks the pool, so watch the strength readout and add length to compensate if needed.
- Tokens are secrets, not identifiers. Store only a hash of a token on the server, set an expiry, and support revocation. Never log a raw token or reuse one across unrelated systems.
- Do not reach for Math.random. This tool uses the cryptographic RNG on purpose. Home-rolled password code that uses Math.random is predictable and unsafe; prefer a vetted generator like this one.
Frequently asked questions
- How random are the passwords and tokens?
- Every character and every byte comes from crypto.getRandomValues, the browser cryptographically secure random number generator (CSPRNG). This tool never uses Math.random for anything, because Math.random is predictable and unsuitable for secrets. Character selection uses rejection sampling so each character in the pool is equally likely, with no modulo bias toward the first few characters.
- What does the strength readout measure?
- It shows entropy in bits, computed as length times log2(pool size). The pool size is the number of distinct characters your selected options allow. For example, 20 characters drawn from a 94-character pool is about 131 bits. More bits means more guesses an attacker must try. The labels are a rough guide: under 40 bits is weak, 40 to 59 is fair, 60 to 127 is strong, and 128 or more is very strong.
- Should I exclude ambiguous characters?
- Excluding the look-alike characters O, 0, l, 1, and I helps when a password will be read aloud, copied by hand, or typed from a printout, since those glyphs are easy to confuse in many fonts. The trade-off is a slightly smaller pool, which lowers entropy a little. If the password is only ever pasted from a manager, leave ambiguous characters in for maximum strength.
- What is the difference between the hex and base64url token formats?
- Both encode the same random bytes. Hex uses 16 symbols (0-9 and a-f) and produces two characters per byte, so 32 bytes becomes a 64-character string. Base64url uses 64 URL-safe symbols (letters, digits, minus, and underscore) and is more compact, roughly 1.37 characters per byte, with no padding. Hex is easy to read and copy, base64url is shorter and safe to drop straight into URLs and headers.
- How many bits of entropy is enough?
- For a random token used as an API key, session identifier, or reset link, 128 bits is the widely cited floor and 256 bits is comfortable. That maps to 16 or 32 random bytes. For a human-typed password, aim for 60 bits or more; a longer passphrase is usually easier to type than a short dense string of the same strength.
- Can I use these tokens as API keys or session identifiers?
- Yes. A 32-byte token carries 256 bits of entropy from a CSPRNG, which is a suitable primitive for session identifiers, password reset links, and API keys. Store only a hash of the token on the server (see the hash generator), set a sensible expiry, and support revocation. Do not reuse a single token across unrelated systems.
- Is anything sent to a server when I generate?
- No. Generation happens entirely in JavaScript on your device. Nothing you generate is uploaded, logged, or stored anywhere off your machine. You can confirm it yourself: open your browser developer tools, switch to the Network tab, and click Generate. You will see zero requests.
Cite this tool
For academic, journalistic, or technical references. Pick a format:
Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.