Random Token Generator

Tokens vs Strings vs UUIDs

"Random token" usually means an unguessable string used to authenticate a request, identify a session, or sign a payload. Three closely related tools, three different jobs:

• Random Token Generator (this tool) — produces tokens in the formats real APIs use: 32-byte hex, Base64url, prefixed alphanumeric. Defaults are tuned for production auth.
• Random String Generator — same CSPRNG, but flexible across length, charset, and quantity. Use it when you need a non-standard format (PIN codes, recovery codes, salt strings).
• UUID Generator — produces RFC 4122 UUIDs (v4 random or v7 sortable). Use it for database primary keys and identifiers in distributed systems where you want a recognized, parseable format.

How Long Should a Token Be?

Token length is governed by entropy. Each byte gives 8 bits. Most modern services use 128–256 bits:

• 16 bytes / 128 bits — session IDs, password reset tokens, email verification. The minimum for anything security-relevant. Express's express-session, Rails' session_id, and most JWT signing keys live here.
• 24 bytes / 192 bits — comfortable middle ground for API tokens.
• 32 bytes / 256 bits — webhook signing secrets (GitHub, Stripe, Slack), HMAC keys, master API keys. The safe default in 2026.
• 64 bytes / 512 bits — long-lived signing keys, root credentials, anything where compromise would be catastrophic. Overkill for most cases.

Below 80 bits, tokens become brute-forceable by determined attackers. Don't use 8-character alphanumeric tokens for anything that matters.

Why Prefixes Matter

Stripe's secret keys start with sk_live_ or sk_test_. GitHub personal access tokens start with ghp_. Webhook signing secrets are whsec_. These prefixes do real work:

• Identifiable in logs — if a token leaks into a stack trace, the prefix says immediately what kind of secret it is and where it came from.
• Automatic leak scanning — GitHub's Secret Scanning feature looks for these prefixes in pushed code. If you accidentally commit sk_live_… to a public repo, GitHub notifies Stripe within minutes and Stripe revokes the key automatically. Same for AWS, Slack, and dozens of other services.
• Rotation — when a service rotates one type of key, finding all places it's used is a simple find-and-replace on the prefix.

Storage and Handling

The token is only as secure as the place you put it. Hard rules:

• Never commit tokens to git. Use .env files for local dev (with .env in .gitignore), and a secrets manager in production (AWS Secrets Manager, HashiCorp Vault, 1Password CLI, Doppler, Cloudflare Workers Secrets).
• Rotate periodically. Once a year at minimum; every 90 days for high-value keys. Always rotate immediately after a suspected breach.
• Use short-lived tokens where possible. Issue a new JWT every few minutes via OAuth refresh, rather than a single long-lived bearer token.
• Log token prefixes, never full values. If you must log token usage, log the first 4–8 chars and the last 4 chars only.
• Use HTTPS for transmission. Bearer tokens over HTTP are visible to anyone on the network path. There is no excuse for this in 2026.

Generating in Code

// Node.js
import { randomBytes } from 'crypto';
randomBytes(32).toString('hex');         // 64-char hex (256-bit)
randomBytes(32).toString('base64url');   // 43-char Base64url

// Python
import secrets
secrets.token_hex(32)        // 64-char hex
secrets.token_urlsafe(32)    // ~43-char Base64url

// Browser
const a = new Uint8Array(32);
crypto.getRandomValues(a);
[...a].map(b => b.toString(16).padStart(2,'0')).join('');

// Bash
openssl rand -hex 32
openssl rand -base64 32 | tr -d '=' | tr '+/' '-_'

For HMAC webhook secrets specifically formatted for GitHub/Stripe/Slack, use the dedicated Webhook Secret Generator.