Generate cryptographically secure random tokens in hex, Base64URL or alphanumeric format — in your browser.
API keys, session identifiers, webhook secrets, password-reset codes and CSRF tokens all share one requirement: they must be impossible to guess. That rules out Math.random(), timestamps and anything derived from them — those are predictable enough to be brute-forced. This generator uses crypto.getRandomValues, the cryptographically secure pseudo-random number generator (CSPRNG) that browsers seed from operating-system entropy — the same source used to create TLS keys.
The length option sets how many random bytes each token contains (16 to 128, default 32) — or, in alphanumeric mode, how many characters. Hex encodes each byte as two characters from 0-9a-f; Base64URL packs the same bytes into a shorter, URL-safe string of letters, digits, minus and underscore; alphanumeric draws characters from the 62-character A-Z a-z 0-9 set. The alphanumeric mode deserves a technical note: because 256 is not divisible by 62, naively taking each random byte modulo 62 would make some characters appear more often than others (modulo bias). This generator instead uses rejection sampling — bytes greater than or equal to 248 are discarded and redrawn — so every character is exactly equally likely.
The status line shows the estimated entropy: 8 bits per byte for hex and Base64URL, log2(62) ≈ 5.95 bits per character for alphanumeric. As a rule of thumb, 128 bits is already infeasible to brute-force and 256 bits — the 32-byte default — is the standard for long-lived API keys. Everything is generated locally in your browser, so no server ever sees the tokens and they are safe to use as real secrets. Treat them accordingly: store only a hash of the token on the server side, show the plain value once, and rotate keys you suspect were exposed.
Entropy = length × log2(alphabet size). A 32-byte token carries 256 bits of entropy in any encoding; an alphanumeric token carries log2(62) ≈ 5.95 bits per character, so 43 alphanumeric characters ≈ 256 bits.
32 bytes (256 bits) is a solid default for long-lived API keys, and 16 bytes (128 bits) is the practical minimum for anything security-relevant. Longer tokens cost nothing here, so err on the generous side.
It is the uneven distribution you get when mapping 256 byte values onto an alphabet that does not divide 256 evenly — some characters become slightly more likely, which measurably reduces effective entropy. This tool avoids it with rejection sampling, discarding bytes above the largest exact multiple of the alphabet size.
No. Tokens are produced locally by crypto.getRandomValues and are never transmitted, logged or stored — this page makes no network requests, so the tokens are safe to use as real secrets.
Only the encoding — the randomness source is the same. Hex is the longest but universally parseable; Base64URL is about a third shorter and safe in URLs; alphanumeric avoids all punctuation, which helps when a system restricts allowed characters.
In theory yes, in practice no: at 256 bits the probability of ever seeing a duplicate is far below that of a hardware fault. Collision resistance is precisely why unguessable random tokens make good identifiers for secrets.
Vai.la turns any URL into a short link with click statistics, QR Code and your own biolink.
Vai.la is not responsible for how the tools are used or for decisions made based on their results.