Random Token Generator
Generate cryptographically secure random tokens in hex, base64, base64url, or UUID format, using the browser's crypto.getRandomValues. Runs locally.
Options
How it works
- Every token is built from
crypto.getRandomValues, the browser's cryptographically secure random source (CSPRNG). - The selected encoding maps the raw bytes to text: hex uses 2 characters per byte, base64 uses 4 characters per 3 bytes, base64url is the URL-safe variant without padding, and UUID is a formatted 16-byte hex string.
- Entropy is set by the byte length, not the encoding — 16 bytes is 128 bits of randomness.
- Generation happens entirely on your device; nothing is transmitted or stored.
About Random Token Generator
Random tokens are unpredictable strings used as credentials or one-time references: API keys, CSRF tokens, session identifiers, password-reset links, and email-verification codes. Their strength depends on how many bits of entropy they hold — 16 bytes (128 bits) is a common default, and 16–32 bytes is ample for most purposes. The encoding only changes the text length, not the entropy: hex renders 2 characters per byte (a 16-byte token becomes 32 characters), while base64 renders 4 characters per 3 bytes (24 characters, 22 without padding); base64url swaps + / for - _ and drops the padding so the token is safe in URLs, query strings, and filenames.
Use this generator whenever you need a fresh random credential: a new API key, a session id, a CSRF token, or a one-time reset link. Entropy must come from a cryptographically secure source — this tool uses crypto.getRandomValues, while Math.random is not designed for security and must never be used for secrets. Store tokens the way you store passwords: hash them in the database so a leak does not expose working credentials, transmit them over HTTPS, and treat anything that cannot be re-derived (like a reset link) as single-use.
The length sets the strength, not the encoding
The length field is in bytes, and it alone determines the entropy: 16 bytes is 128 bits, 32 bytes is 256. Everything else here is presentation. Hex renders two characters per byte, so 16 bytes becomes 32 characters; base64 renders four characters per three bytes, giving 24 characters with padding or 22 without; base64url additionally swaps `+` and `/` for `-` and `_` so the value survives a URL, a query string or a filename unchanged.
This page offers lowercase hex, uppercase hex, standard base64, base64url and a UUID-style layout, in sizes from 4 to 128 bytes, producing one to ten values per run. 128 bits is already far past any practical brute-force concern — the realistic failure mode for a token is leakage through logs, analytics or a shared screen, not guessing, so spend your effort on storage and expiry rather than on adding bytes.
Why not Math.random
`Math.random()` is a fast non-cryptographic generator — V8 implements xorshift128+ — designed to be cheap, not to be unpredictable. Its internal state is small enough that observing a handful of consecutive outputs is enough to reconstruct the state and predict every value that comes after, which means anything derived from it has to be treated as public the moment it is used for a secret.
`crypto.getRandomValues` draws from the platform CSPRNG instead. Its one real constraint is a quota of 65,536 bytes per call, raised as a `QuotaExceededError` — nothing you will hit at these sizes. Use it for session identifiers, CSRF tokens, API keys, reset links and email verification codes, and if you need something shorter than 16 bytes, prefer a dedicated tool for the format rather than truncating a longer token.
Storing and retiring what you generate
Store bearer tokens hashed. Because a token already carries 128 bits of entropy there is nothing to slow down, so a fast digest such as SHA-256 is the correct storage function here — unlike a password, wrapping it in bcrypt or Argon2 adds latency on every authenticated request without adding any security, since the search space is not the bottleneck.
Expiry and single-use behaviour matter more than length. A password-reset token should be invalidated after one redemption and after minutes rather than hours, and the presented value should be compared against the stored hash in constant time rather than with `===`. One formatting note: the UUID option here lays out 16 random bytes as 8-4-4-4-12 without setting the RFC 4122 version and variant nibbles, so hand it to code expecting an opaque random string, not a spec-compliant v4 UUID.
Frequently Asked Questions
How do I generate a random token?
What is the difference between token types?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.