How many bytes should my token be?

The minimum for any security-sensitive token is 128 bits (16 bytes). For API keys and access tokens, the industry standard is 256 bits (32 bytes). For JWT signing secrets, use 256 bits for HS256 and 512 bits (64 bytes) for HS512.

What is the difference between Hex, Base64, and Base64URL?

Hex encodes each byte as two hex characters — universally safe everywhere. Base64 is more compact but uses + and / that need URL-encoding. Base64URL replaces + with - and / with _, making it safe in URLs, JWTs, and cookies without escaping.

Free Secure Token Generator

Generate cryptographically secure random tokens, API keys, hex strings, Base64URL secrets and UUIDs. Everything runs in your browser — nothing is ever sent to a server.

Token Format

Token Length (bytes)

32 256 bits

4 bytes326496128 bytes

Options

Uppercase Output No Base64 Padding (=)

Your Token

Generate multiple unique tokens at once — ideal for seeding test databases, provisioning API credentials in bulk, or creating one-time verification codes for large user batches.

Token Format

Token Length (bytes)

43264128

Quantity

Generated Tokens

Build structured API keys with a custom prefix — the same pattern used by Stripe (sk_live_), OpenAI (sk-), and GitHub (ghp_). The prefix identifies your service; the cryptographically random suffix provides the security.

Random Suffix Length (bytes)

32 256 bits

16 bytes324864 bytes

Custom Prefix (optional — e.g. sk-, pk_live_, token_)

Include Separator (_) Wrap as ENV Variable

Your API Key

Common Use Cases

API Keys

JWT Secrets

Session Tokens

CSRF Tokens

Email Verify

Reset Links

All tokens generated in your browser Uses crypto.getRandomValues() Nothing ever sent to a server

Token Size & Format Reference Guide

Show

Size	Entropy Bits	Recommended Use	Rating
8 bytes	64 bits	Short codes, PIN tokens (short-lived only)	Minimum
16 bytes	128 bits	CSRF tokens, email verification, session IDs	Adequate
32 bytes	256 bits	API keys, access tokens, password reset links	Recommended ✓
48 bytes	384 bits	Long-lived credentials, refresh tokens	Strong
64 bytes	512 bits	JWT signing secrets, symmetric encryption keys	Very Strong ✓

Format Comparison

Hex — 2× byte length, safe everywhere [0-9a-f]
Base64 — 1.33× bytes, uses +/ (needs URL encoding)
Base64URL — URL-safe, replaces +/ with -_ no padding
Alphanumeric — [A-Za-z0-9] only, URL-safe, human-readable

Security Best Practices

Always use ≥ 128 bits (16 bytes) minimum
Rotate API keys every 90 days
Hash tokens before storing in database
Never log or expose raw secrets

100% client-side — no server contact

Cryptographically secure randomness

Free, no sign-up needed

What This Secure Token Generator Does

Switch between three modes using the tabs. Single Token generates one token at a time in your chosen format — Hex, Base64, Base64URL, Alphanumeric or UUID v4 — with a byte-length slider that shows the entropy in bits as you adjust it. Bulk Generate produces up to 100 tokens in one pass with a line-by-line output ready to copy or download as a .txt file. API Key Builder constructs structured prefixed keys matching the format used by Stripe, OpenAI, GitHub and other major APIs, with an optional ENV variable wrapper for direct use in configuration files.

All generation uses crypto.getRandomValues() — the browser's cryptographically secure pseudorandom number generator seeded from hardware entropy. Nothing is sent to any server, nothing is logged, and the tool works fully offline once loaded. The Token Size Reference card explains which byte length to choose for each use case, and the Format Comparison panel clarifies when to choose hex versus Base64URL.

Tips for Getting the Best Results

For API keys and access tokens, use 32 bytes (256 bits) in Hex or Base64URL format. This is what Stripe, GitHub and most major cloud providers use and is well within the computationally uncrackable range for any realistic threat model.
For JWT signing secrets (HMAC-SHA256), use at minimum 32 bytes — the secret should be at least as long as the hash output. For HS512, use 64 bytes. Generate in Hex or Base64URL and store in an environment variable or secrets manager.
For CSRF tokens and email verification links, 16 bytes (128 bits) is sufficient since these are short-lived and single-use. Use Base64URL for tokens that will appear in URLs.
For session IDs in cookies, 32 bytes in Hex or Base64URL produces a token that is trivially unique and computationally indistinguishable from random at any realistic scale.
Always hash tokens before storing them in your database — store only the SHA-256 hash and compare by hashing the submitted value. Use our Hash Generator to test the hashing step, or our Bcrypt Hash Generator for password-like secrets that need an adaptive cost factor.
Use the API Key Builder tab to generate structured prefixed keys. Include a version or environment indicator in the prefix (sk_live_ vs sk_test_) so automated scanning tools like GitHub's secret detection can identify accidentally committed keys.

Frequently Asked Questions

What makes a token cryptographically secure?

A cryptographically secure token is produced by a CSPRNG — a Cryptographically Secure Pseudo-Random Number Generator — rather than a standard random function like Math.random(). The distinction is fundamental: Math.random() uses a deterministic algorithm that can be seeded and predicted given enough observations, making it entirely unsuitable for security-sensitive values. An attacker who knows the algorithm and seed can reproduce every "random" value ever generated.

This tool uses the Web Cryptography API's crypto.getRandomValues(), which draws entropy from hardware noise sources: CPU timing jitter, interrupt timing, network packet timing, and device sensor variation depending on the platform. The output is statistically indistinguishable from true randomness and matches the quality produced by crypto.randomBytes() in Node.js or RAND_bytes() in OpenSSL. Every token generated here — in any format — carries the same underlying cryptographic quality. For generating human-memorable credentials alongside machine tokens, our Password Generator uses the same CSPRNG with character set controls optimised for passwords.

How many bytes should my token or secret be?

The minimum for any security-sensitive token is 128 bits (16 bytes). Below this threshold, high-speed distributed guessing attacks become practical within hours or days using GPU clusters running billions of guesses per second. For API keys, access tokens and password reset URLs, the modern industry standard is 256 bits (32 bytes) — this is what Stripe, GitHub, AWS, and most major cloud providers generate for their credentials. At 256 bits, even a theoretical attacker with all the computing power on Earth could not exhaust the search space before the heat death of the universe.

For long-lived credentials such as refresh tokens or OAuth client secrets, 384 bits (48 bytes) adds a meaningful safety margin against future increases in computing power. JWT signing secrets for HMAC-SHA256 should match the output length of the hash function — at minimum 256 bits (32 bytes) for HS256, and 512 bits (64 bytes) for HS512 to avoid the secret becoming the weakest link in the signing chain. UUID v4 provides 122 bits of randomness — adequate for database identifiers but below the recommended minimum for authentication tokens where brute-force resistance is the primary security requirement. The Token Size Reference panel summarises all recommended sizes at a glance.

What is the difference between Hex, Base64, Base64URL and Alphanumeric?

Hex encodes each byte as two lowercase hexadecimal characters from the set 0–9 and a–f. A 32-byte token becomes a 64-character string. Hex is universally safe in URLs, HTTP headers, JSON payloads, database columns, log files and configuration files without any escaping or transformation — making it the most practical default for tokens that need to travel across multiple systems. Its only downside is verbosity: it is exactly twice the byte count.

Base64 maps every three bytes to four characters using A–Z, a–z, 0–9, plus (+) and slash (/), with equals (=) padding to maintain 4-character block alignment. It is approximately 33% more compact than hex but the plus and slash characters require percent-encoding in URLs and may need escaping in JSON strings or query parameters in some frameworks. Base64URL is a URL-safe variant standardised in RFC 4648 that replaces + with hyphen (-) and / with underscore (_), and optionally omits padding. This is the standard encoding for JWT payloads, OAuth 2.0 bearer tokens, cookie values and URL parameters — if your token will appear in any of those contexts, Base64URL is the correct choice. Alphanumeric uses only A–Z, a–z and 0–9 — no special characters — at slightly reduced entropy density. It is ideal for SMS verification codes, invite codes, voucher codes, or any system with strict character restrictions that cannot handle symbols.

When should I use UUID v4 from this tool versus the UUID Generator?

Both this tool and our UUID / GUID Generator produce RFC 4122 compliant UUID v4 values using crypto.getRandomValues() — the output is identical in quality. The difference is context and workflow. This tool is appropriate when you need a UUID as one option among several token formats — for example, when deciding whether to use UUID v4 or a 32-byte hex token for a particular use case — and want to see the entropy figure alongside it. It also integrates naturally into the Bulk Generate workflow if you need UUID v4 tokens in bulk alongside other format types.

Our UUID / GUID Generator is the better choice when UUID generation is the primary purpose — it also supports UUID v1 (timestamp-based) and v5 (name-based deterministic), offers multiple output formats (standard, braced, no-hyphens, URN), a UUID structure reference guide, and a version comparison panel. For applications that specifically need sortable, time-ordered identifiers or deterministic UUIDs derived from namespace plus name, that tool provides the full feature set. If you only ever need v4 in standard format, either tool works equally well.

What is a structured API key and why use a prefix?

Industry leaders use structured API keys because prefixes solve two practical problems simultaneously: accidental exposure detection and instant recognition. Stripe uses sk_live_ for live secret keys and sk_test_ for test keys. OpenAI uses sk-. GitHub uses ghp_ for personal access tokens, github_pat_ for fine-grained personal access tokens, and ghs_ for GitHub Apps. The prefix makes it trivially possible for automated scanning tools — including GitHub's built-in secret scanning, GitLab's secret detection, AWS Macie, and third-party tools like TruffleHog and Gitleaks — to detect accidentally committed API keys in source code repositories.

The prefix also lets developers, support teams and security engineers instantly identify a key's type, environment and issuing service from a log line or error message without needing to query a database. Using sk_live_ versus sk_test_ prevents the wrong key being used in the wrong environment — a common and costly mistake in development workflows. The cryptographically random Base64URL suffix carries all the actual security; the prefix contributes nothing to entropy but everything to operational clarity. This tool's API Key Builder lets you specify any prefix up to 32 characters, choose whether to include an underscore separator between prefix and suffix, and optionally wrap the output as an environment variable assignment ready to paste into your .env file.

Should tokens be hashed before storing in a database?

For most token types, yes. Storing raw tokens in a database means that anyone who obtains a database dump — through SQL injection, a misconfigured backup, a compromised employee account, or any other breach scenario — can immediately use every token without any additional work. Storing only a hash means the attacker must crack each token individually before exploiting it. For a 256-bit random token, this is computationally infeasible regardless of the hash algorithm speed — the search space is simply too large.

The standard workflow is: generate a random token, send the raw token to the user (in a URL or response body, shown once), store only the SHA-256 or SHA-512 hash in your database, then verify future submissions by hashing the submitted token and comparing it to the stored hash using a constant-time comparison function to prevent timing attacks. Use our Hash Generator to test this hashing step during development. For API keys specifically, a common pattern stores the prefix unencrypted (for display and lookup) alongside the hash of the full key (for verification), so users can identify which key they are using without exposing the secret. For password-like secrets where an adaptive cost factor is needed to slow brute-force attempts, use our Bcrypt Hash Generator.

What makes a JWT secret strong and how should I store it?

A JWT secret is the cryptographic key used with HMAC algorithms (HS256, HS384, HS512) to sign and verify JSON Web Tokens. A weak or guessable secret is catastrophic — an attacker who recovers it can forge any JWT claim including user ID, role, account tier or token expiry time, giving them arbitrary access to your application without valid credentials. NIST SP 800-107 recommends a secret length at least equal to the security strength of the hash function: 256 bits for HS256, 384 bits for HS384, and 512 bits for HS512.

Always generate your JWT secret using a CSPRNG — which this tool does via crypto.getRandomValues(). Never derive it from a human-typed passphrase, a UUID, an incrementing sequence, an application name, or any other guessable value. Never commit it to source code, configuration files in version control, or any file that might be accidentally exposed. Store it exclusively in an environment variable or a dedicated secrets manager such as AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Rotate the secret immediately on any suspected exposure event — this invalidates all existing tokens, so plan for a re-authentication window. If you need to verify the structural entropy of any existing secrets before rotation, our Password Strength Checker provides an entropy estimate and crack-time analysis.

How is this different from the Password Generator?

Our Password Generator creates credentials optimised for human use: length controlled in characters rather than bytes, options to avoid visually ambiguous characters for manual typing, passphrase mode for memorability, and character set controls for site-specific complexity requirements. The output is intended to be typed or copied by a person into a login field. This Secure Token Generator creates machine-to-machine credentials where human legibility is irrelevant and what matters is protocol compatibility and raw entropy density.

Length here is controlled in bytes — the unit that directly corresponds to entropy bits — and output formats are chosen for protocol fit: hex for HTTP headers and database columns, Base64URL for JWT payloads and OAuth tokens, UUID for database primary keys, alphanumeric for SMS codes. Tokens generated here are never typed manually; they belong in environment variables, secrets vaults, HTTP Authorization headers and database rows. Both tools use crypto.getRandomValues() internally, so the underlying cryptographic quality is identical — only the output format and intended deployment context differ.

Can I use these tokens as CSRF protection and how do CSRF tokens work?

Yes. CSRF (Cross-Site Request Forgery) protection works by embedding a unique, unpredictable secret token in every state-changing form or AJAX request. When the server receives the request, it verifies that the submitted token matches the one it issued to that user session. Because the token is secret and same-origin policy prevents cross-origin JavaScript from reading it, a malicious page on another domain cannot forge a valid request on the user's behalf even if the user is logged in.

For CSRF tokens, 16 bytes (128 bits) in Base64URL or Hex format is widely accepted as sufficient — these tokens are session-scoped and single-use or session-duration, so even a faster-than-realistic attacker cannot enumerate the space before the session expires. Generate a token with this tool, include it as a hidden form field or custom HTTP header (X-CSRF-Token), store the expected value server-side in the user's session, and validate on every mutating request (POST, PUT, PATCH, DELETE). Never include the CSRF token in the URL where it might appear in server logs or Referer headers. Pair CSRF protection with SameSite=Strict cookies for defence in depth — the two controls together defeat the attack even if one is misconfigured.

How do I generate tokens server-side in my own application?

For production applications, generate tokens on the server using your language's canonical CSPRNG rather than relying on a browser tool. The equivalent calls in major platforms are: crypto.randomBytes(32).toString('hex') in Node.js, secrets.token_hex(32) or secrets.token_urlsafe(32) in Python, SecureRandom.hex(32) in Ruby, bin2hex(random_bytes(32)) in PHP, java.security.SecureRandom in Java, crypto/rand package in Go, and rand::thread_rng() with the rand_core crate in Rust. All of these draw from the operating system's entropy pool (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows) and produce cryptographically secure output.

This browser-based tool is most useful for one-time manual tasks — generating a JWT secret to paste into a secrets manager, creating a test API key during development, or producing a batch of tokens for a CSV import. For any automated generation within your application — per-request CSRF tokens, new user API keys, password reset URLs, email verification links — always generate server-side so the token never needs to be transmitted to the client before it is assigned. Store the SHA-256 hash using our Hash Generator as a reference for the hash value, and protect user passwords with our Bcrypt Hash Generator.