What does batch generation with export do?

Set the count to a value between 2 and 100 and click Generate to create many tokens at once — useful when provisioning API keys for a team or an integration. The batch view lets you copy each token individually or as an Authorization: Bearer <token> header, copy the whole set, and export it as TXT (one per line), CSV , or JSON . Everything is generated locally in your browser.

Is the token generator free and private?

Yes. Everything runs in your browser with crypto.getRandomValues() — the same CSPRNG the browser uses for TLS and WebAuthn. Nothing you type is uploaded, logged, or stored anywhere. You can even use it offline, and once you close the tab every generated token is gone from memory.

Secure Opaque Token Generator

Generate high-entropy tokens for sessions and API keys — batch mode, standard Base64, prefix/suffix, and copy as a Bearer header.

Result

Random core length

8–256 characters

Alphabet

Count

1–100 · 1 = single token

Prefix

Optional · max 32 chars

Suffix

Optional · max 32 chars

Random core entropy: ≈ 192 bits per token (32 chars × 64-char alphabet). A prefix or suffix only labels the token — it adds no randomness.

Tokens are random and opaque; you can store related data on your server keyed by this token. Delete the server-side record to revoke instantly.

What is Opaque Token Generator?

An opaque token is a random string your server uses as a pointer: every request presents it, and the server looks it up in its own store. There is no payload to read, no signature to verify, and nothing sensitive sits on the client — the token stops working the moment its server-side record is deleted.

The generator adds the conveniences you usually bolt on yourself:

Standard Base64 alphabet — RFC 4648 Base64 (A–Z a–z 0–9 + /) alongside the URL-safe, Base62, hex, and extended sets.

Batch generation with export — create up to 100 tokens at once and export them as TXT, CSV, or JSON.

Prefix / suffix customization — tag tokens like sk_live_ or _prod for environment and key-type scoping.

Copy as Bearer header — copy any token ready to paste as Authorization: Bearer <token>.

Revocable by design — the server-side record is the source of truth; deleting it invalidates the token immediately.

Zero-Server Tool Data Guarantee

All tokens are generated locally in your browser using the Web Crypto API (crypto.getRandomValues). No token data ever leaves your device — generated tokens, prefixes, and suffixes are never transmitted to any server.

How to Use

Set Length and Alphabet

Choose a random-core length (8–256) and an alphabet — URL-safe, standard Base64, Base62, hex, or extended URL-safe.

Configure Batch and Shape

Set the count (1–100) for single or batch output, and add an optional prefix or suffix to scope the tokens.

Generate

Click 'Generate' to create cryptographically secure random tokens using crypto.getRandomValues().

Copy or Export

Copy any token, copy it as an 'Authorization: Bearer <token>' header, or export the whole batch as TXT, CSV, or JSON.

Common Use Cases

Session Identifiers

Generate secure session tokens for httpOnly cookies. Your server maps the token to a user session in Redis or a database.

API Key Provisioning

Batch-generate keys for teams or integrations, scope them with prefixes like sk_live_, and export the set as CSV or JSON for your records.

OAuth 2.0 Bearer Tokens

Issue opaque bearer tokens and validate them with an Authorization header. Revoke instantly by deleting the server-side record.

Password Reset Tokens

Generate one-time-use tokens for password reset flows. The token is stored server-side with a short expiration window.

Environment Scoping

Use prefix/suffix markers to distinguish production, staging, and sandbox keys without decoding the token.

Implementation Examples

JavaScriptBrowser — batch + prefix (Web Crypto)

// Generate N URL-safe tokens with an optional prefix/suffix
const ALPHABET_URL = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
const ALPHABET_B64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";

function randomByte() {
    return crypto.getRandomValues(new Uint8Array(1))[0];
}

function randomToken(length, alphabet = ALPHABET_URL) {
    const size = alphabet.length;
    const limit = 256 - (256 % size); // reject bytes that would bias the output
    let out = "";
    for (let i = 0; i < length; i++) {
        let b;
        do { b = randomByte(); } while (b >= limit);
        out += alphabet[b % size];
    }
    return out;
}

function generateBatch(count, length, { prefix = "", suffix = "", alphabet = ALPHABET_URL } = {}) {
    return Array.from({ length: count }, () => prefix + randomToken(length, alphabet) + suffix);
}

const tokens = generateBatch(10, 32, { prefix: "sk_live_" });
// tokens: ["sk_live_a3f8c1e2b4d6...", "sk_live_9b0c…", ...]

// Send the first token as a Bearer header
fetch("/api/me", { headers: { Authorization: "Bearer " + tokens[0] } });

Opaque Tokens vs JWTs

Feature	Opaque Token	JWT
Contains user data	No (lookup key only)	Yes (claims payload)
Validation	Database / cache lookup	Cryptographic signature
Revocation	Instant (delete record)	Difficult until expiration
Token size	Fixed (e.g., 32 bytes)	Grows with claims
Server-side storage	Required	Optional (stateless)
Best for	Sessions, API keys	Stateless auth, microservices

Production Best Practices & Security

Use at least 32 random characters — shorter tokens are easier to brute-force; 32 URL-safe characters give ~192 bits of entropy. Why:an attacker can enumerate a small token space with repeated requests; ~192 bits makes brute-force attacks practically impossible.

Use standard Base64 only when you control storage and transport — the + and / characters (and = when padded) require URL-encoding in query strings and paths. Why:a + is decoded as a space in form-encoded URLs and a bare / can break path parsing, so these tokens get mangled in transit; URL-safe alphabets avoid that class of bug entirely.

Treat prefix/suffix as metadata, not entropy — a guessable prefix like sk_live_ does not strengthen the token. Why:only the random core contributes security; keep the core at least 32 characters even when you add a prefix.

Store only a hash of the token server-side — e.g. SHA-256 — so a database leak does not expose usable tokens. Why:a hashed token is useless to an attacker even if the entire store is dumped, while you can still look up sessions by hashing each presented token.

Rotate tokens on privilege change — issue a new token when a user's role or permissions change to prevent stale access. Why:a token issued before a privilege change still maps to the old permissions in your server-side store; rotation forces re-validation.

Generate with crypto.getRandomValues — never Math.random(). Why:Math.random() uses a predictable PRNG an attacker can reproduce; the Web Crypto API draws on hardware-backed CSPRNG entropy.

Frequently Asked Questions

An opaque token is a randomly generated string your server uses as a pointer: every request presents it, and the server looks it up in its own database or cache. The token is meaningless everywhere else.

Where a JWT carries claims inside itself, an opaque token carries none — who the user is and what they may do lives server-side, keyed by the value.

That is exactly why revocation is so clean: remove the record and the token stops working on the very next request. It is the standard choice for session cookies and OAuth 2.0 bearer tokens.

Choose opaque tokens when server-side revocation matters. Because the token is only a lookup key, you can kill it instantly by deleting the stored record — a logged-out session, a revoked API key, or a cancelled account stops working on the very next request, with no blacklist and no key rotation.

Choose JWTs when you need stateless verification — many microservices that do not share a database must validate a token without a lookup — or when clients need to read claims (like a user role) directly from the token without a round trip.

The trade-off is real: a JWT stays valid until it expires, so 'revoking' it means either waiting, building a denylist, or rotating the signing key — all of which reintroduce the server-side state opaque tokens never needed. If your stack can afford a lookup per request, opaque tokens are simpler and harder to misuse.

Revocation is a simple server-side delete. On logout, password change, or key rotation, remove the token's record from your store and it becomes invalid immediately — no signing keys to rotate, no blacklist to maintain.

Best practice is to store only a hash of the token (for example, SHA-256) rather than the raw value, so a database leak does not expose usable tokens. Verification is then: hash the presented token and look up the hash.

The alphabet determines which characters appear in your generated token.

'URL-safe' (Base64URL, using A-Z, a-z, 0-9, -, _) is the standard choice for OAuth 2.0 bearer tokens and API secrets. It never requires URL encoding and has no visually confusing characters.

'Standard Base64' (RFC 4648, A-Z, a-z, 0-9, +, /) matches the exact character set some systems and SDKs expect when decoding tokens as raw bytes. Use it only when you control storage and transport — the + and / characters need URL-encoding in query strings and paths.

'Base62' (A-Z, a-z, 0-9) keeps tokens purely alphanumeric — no punctuation at all — which can simplify handling in systems that restrict special characters.

'Hex' (0-9, a-f) is useful for systems that only accept hexadecimal input, like some legacy databases or configuration systems. But it produces tokens about 50% longer for equivalent entropy.

'Extended URL-safe' adds . and ~ to the URL-safe set, giving the largest alphabet and the most compact tokens.

Standard RFC 4648 Base64 uses the characters + and / (and = when padded), which the default URL-safe alphabet deliberately avoids.

Choose Standard Base64 when the receiving system expects that exact character set — for example an existing database column or an SDK that decodes the token as raw bytes. Otherwise prefer URL-safe: the + is decoded as a space in form-encoded URLs and a bare / can break path parsing, so these tokens get mangled in transit.

Prefixes and suffixes tag a token with structure, like sk_live_ for a production secret key or _test for a staging environment. They let you tell key types apart and route them correctly without decoding anything.

They do not add entropy — the security comes entirely from the random core. The tool keeps the prefix and suffix separate from the length setting, so a 32-character token with a sk_live_ prefix still has a full 32-character random core (~192 bits).

For most use cases, 32 characters is the standard. A 32-character URL-safe token provides about 2¹⁹² possible values, making brute-force attacks practically impossible.

For session tokens and OAuth bearer tokens, 32 characters is more than sufficient. Use 16 characters for low-security contexts like temporary identifiers, and 64+ characters when the token needs to serve as a cryptographic key or when compliance requires it.