Random Token Generator
Create cryptographically random token or API-key secret material with selectable alphabets, unbiased character selection, and visible search-space estimates.
Range: 8–512 characters. With base64url alphabet, 22 characters crosses a nominal 128-bit search space.
64 URL-safe characters; sampled directly rather than Base64URL-encoding a byte array.
Generated token
Browser-local generation
Random bytes come from crypto.getRandomValues() and token construction runs in the browser. The generator code does not send generated values to a server. A copied secret can still enter clipboard history, logs, screenshots, shell history, or another application, so production handling matters after generation.
Where the randomness comes from
Browser crypto.getRandomValues() supplies cryptographically strong random values rather than the predictable pseudo-random output intended for simulations and UI effects. MDN documents the browser API and its security properties in the Crypto.getRandomValues reference.
Mapping a random byte with a simple remainder operation can favor some characters whenever the alphabet size does not divide 256 evenly. Rejection sampling avoids that bias: bytes above the largest evenly divisible range are discarded and replaced before character selection.
Base64URL alphabet is not the same as Base64URL encoding
The Base64URL option samples directly from the 64-character alphabet A–Z a–z 0–9 - _. It therefore produces URL-safe token text, but it is not claiming that the result is the canonical Base64URL encoding of a particular underlying byte sequence.
The URL- and filename-safe alphabet itself is standardized in RFC 4648 section 5. That distinction matters when another protocol expects encoded binary bytes rather than merely a random string drawn from the same characters.
Choose length from the alphabet, not from habit
| Alphabet | Possible characters | Characters for ≥128 nominal bits |
|---|---|---|
| Base64URL alphabet | 64 | 22 |
| Alphanumeric | 62 | 22 |
| Lowercase hexadecimal | 16 | 32 |
| Numeric only | 10 | 39 |
“128 bits” here is a search-space reference, not a universal token requirement. Short-lived numeric verification codes often use smaller spaces and rely heavily on expiry plus server-side attempt limits; long-lived bearer secrets generally deserve a much larger guessing margin.
A random string becomes a credential only after your system gives it meaning
API or webhook secret
Associate the value with the intended account or integration, restrict permissions, keep it out of logs, rotate it, and provide a revocation path. A random string by itself has no identity or authorization semantics.
Reset or verification value
Set a short lifetime, make successful use consume the value, limit repeated guesses, and avoid exposing it through analytics, referrers, logs, or URLs longer than necessary.
Session identifier
Randomness is only the identifier layer. Browser sessions also need appropriate cookie transport and script-access controls, renewal rules, server-side invalidation, and protection against session fixation.
Stored bearer token
Consider whether the server needs the raw token after issuance. For many lookup-style bearer tokens, storing a one-way verifier rather than the raw secret can reduce damage if the credential database leaks.
When the token is an API key
A production API-key system often separates a public identifier or short prefix from the secret portion. The identifier lets the server locate the right credential record without indexing, logging, or exposing the complete secret.
Server-side verification
If the server only needs to test whether a presented key matches, a one-way verifier can reduce exposure compared with storing the raw secret. If another system must later receive the original credential, the storage design has different requirements.
Transport and operations
Prefer authorization headers over query-string credentials when the protocol allows it, avoid source control and client bundles, log an identifier instead of the full key, scope permissions, and support independent rotation and revocation.
Failures that still happen with strong random text
- Putting production secrets in source control, client-side bundles, support tickets, screenshots, or application logs.
- Giving a long-lived token broad permissions when a narrower scope or shorter lifetime would do.
- Generating a good token but comparing it insecurely, leaking it in URLs, or never providing a revocation path.
- Assuming a “unique-looking” value is automatically an API key, session, CSRF token, or password-reset design.
- Using numeric-only values without compensating for their much smaller guessing space.