Is this random secure enough for production?

Yes. The tool uses crypto.getRandomValues from the Web Crypto API, the browser's cryptographically secure pseudo-random number generator. It is suitable for session tokens, CSRF tokens, and reset links, unlike Math.random which must never be used for secrets.

How many bytes should a token be?

For session and CSRF tokens, 32 bytes (256 bits) is a widely recommended minimum. Shorter 16-byte tokens are acceptable for low-risk identifiers, while sensitive long-lived secrets may use 48 or 64 bytes.

What is the difference between base64 and base64url?

Standard base64 uses the characters plus and slash and may include equals padding, which are unsafe in URLs. Base64url replaces them with hyphen and underscore and drops padding, making the token safe to drop directly into a URL or filename.

Are the tokens sent anywhere?

No. Generation happens entirely in your browser and no token is logged, transmitted, or stored on any server. Treat the values as live secrets and store them securely.

Why does hex look twice as long as the byte count?

Hexadecimal encodes each byte as two characters, so 32 bytes become a 64-character string. Base64 is more compact, encoding roughly every 3 bytes as 4 characters.

What is the Secure Token Generator?

Generate cryptographically secure random tokens in hex, base64, and base64url encodings at any byte length. Built on the Web Crypto API and runs entirely in your browser, ideal for session IDs, CSRF tokens, API keys, and password-reset links. It runs free in your browser on Gera Tools, with nothing uploaded.

Secure Token Generator

Name: Secure Token Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

A secure token is a string of unguessable random data used to authenticate or identify a request — session identifiers, CSRF tokens, API keys, password-reset links, and email-verification codes all rely on them. The single most important property is that the value must come from a cryptographically secure random source. This tool generates tokens using the browser’s Web Crypto API, so every value is suitable for real authentication systems, and nothing ever leaves your device.

How it works

The generator draws random bytes directly from crypto.getRandomValues, the browser’s cryptographically secure pseudo-random number generator (CSPRNG). It then encodes those raw bytes into a text form you can paste into code:

Allocate a Uint8Array of the byte length you chose.
Fill it with crypto.getRandomValues(bytes).
Encode the bytes as hex, standard base64, or URL-safe base64url.

Critically, this never uses Math.random, which is predictable and must never be used for anything security-sensitive. A token built from 32 secure random bytes has 256 bits of entropy — far beyond brute-force reach.

Encodings and sizes

Hex doubles the byte count in characters (32 bytes = 64 hex chars) and is the easiest to read, but least compact.
Base64 is compact (about 4 characters per 3 bytes) and standard for HTTP headers and cookies.
Base64url swaps +/ for -_ and removes = padding so the token is safe to embed directly in URLs and filenames without percent-encoding.

Choosing the right byte length

Use case	Recommended bytes	Why
CSRF tokens	32 bytes	256-bit space; standard recommendation
Session IDs	32 bytes	Same — cookie or header transport
Password-reset links	32–48 bytes	Should expire quickly; 32 is fine
Long-lived API keys	32–64 bytes	More bytes provides deeper margin
Low-risk identifiers	16 bytes	128-bit entropy; adequate for most

Going below 16 bytes risks collision in large-scale systems. Going above 64 bytes has no practical security benefit and wastes storage.

Common mistakes

Using Math.random. This is not cryptographically secure. Node.js’s crypto.randomBytes, Python’s secrets.token_hex, and the browser’s crypto.getRandomValues are correct; Math.random is never acceptable for security-sensitive tokens.

Storing tokens in plaintext. Password-reset tokens and one-time codes stored in plain text in a database can be read by anyone with database access. Hash them with SHA-256 before storage — the link carries the raw token, the database holds the hash.

Reusing tokens. Each token should be single-use. Mark reset and verification tokens as used the moment they are consumed, so replaying an intercepted token does nothing.

For session and anti-CSRF tokens, 32 bytes is a strong, conventional choice. Always store generated secrets in a secure secret manager, never in source control, and rotate them if exposure is suspected.