Generators

Random String Generator

Generate secure random strings from a chosen alphabet.

Output
Result
Options

About this tool

Random strings serve as API keys, session tokens, temporary passwords and test fixtures. What makes them fit for purpose is not looking random but being unpredictable, and that depends entirely on the source of randomness.

These are produced with crypto.getRandomValues(), your browser's cryptographically secure generator, entirely on your machine. The generated strings are not transmitted or logged by this tool, so using it does not share those values with anyone else.

How to use it

  1. Set the optionsChoose how many values you need and how they should be formatted.
  2. GeneratePress Generate, or use Ctrl+Enter (Cmd+Enter on macOS).
  3. Copy or downloadCopy the result to your clipboard or save it as a file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Two 24-character alphanumeric strings

Input

Output

k3Jx9mQp2vRt7wYz4nBc8fHd
aG5tL8sW3xKm9pQv2zRy6cNj

About 143 bits of entropy each, suitable for an API key.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Why the randomness source is the whole question
Math.random() is fast and adequate for shuffling a list, but its internal state can be recovered from a handful of outputs, which means future values become predictable. For anything that grants access, that is fatal. This tool uses the Web Crypto API, which draws from the operating system entropy pool.
Length, alphabet and actual strength
Security comes from total entropy, which is length multiplied by the bits each character contributes. A 62-character alphabet gives about 5.95 bits per character, so a 22-character string carries roughly 131 bits, comparable to a UUID. As a rule of thumb, 128 bits or more is appropriate for a long-lived secret; a 16-character alphanumeric string (about 95 bits) is reasonable for a short-lived token.
Excluding ambiguous characters
The option to remove 0, O, 1, l and I trades a little entropy for a lot of usability when a value will be read aloud, typed from a screen, or transcribed from paper. For a code a human must handle, that trade is usually worth making, compensate by adding a couple of characters to the length.
Symbols and where they break
Symbols add entropy per character but cause problems in practice: they need escaping in URLs, shell commands and config files, and are easy to mangle when copied. For machine-to-machine tokens, a longer alphanumeric string is usually better than a shorter one with punctuation.
These are not password hashes
A generated string is a secret to be stored securely, not a password verifier. If you are issuing a temporary password, hash it with bcrypt, scrypt or Argon2 before storage, never keep the plain value.

Limitations

  • Maximum 512 characters per string and 500 strings per run.
  • Generates secrets, not password hashes, hash before storing a password.

Questions

Are these safe for API keys and tokens?
Yes, provided the length is adequate. They come from the same cryptographic source a server-side library uses, and are generated locally without transmitting the generated strings.
How long should my token be?
For a long-lived secret aim for 128 bits or more, about 22 alphanumeric characters. Short-lived codes can be shorter, around 16 characters for roughly 95 bits.
Should I include symbols?
Usually not for machine tokens, because they need escaping in URLs and shells. Add length instead; it achieves the same strength without the handling problems.

Related tools