MyCalcBuddy

Token Generator

Generate various types of authentication tokens for testing and development.

Warning: These tokens are for testing and development purposes only. Do not use generated tokens in production authentication systems.

What Is an Authentication Token?

An authentication token is a compact, self-contained credential that proves identity or grants access to a resource. Rather than sending a username and password with every request, modern web applications issue a token after a successful login and then validate that token on subsequent requests. This pattern decouples authentication from authorization and makes stateless APIs possible.

Tokens come in several forms depending on their purpose. A JWT-like token encodes a signed JSON payload that carries claims such as user ID and expiry. A bearer token is an opaque random string — whoever holds it can present it to gain access, much like a bus ticket. A session token maps a random identifier to server-side session data. A CSRF token is a short-lived value embedded in HTML forms to prevent cross-site request forgery. A refresh token is a long-lived credential used to obtain new short-lived access tokens. An OAuth access token follows the format used by OAuth 2.0 providers to delegate limited access.

This token generator uses the browser's built-in crypto.getRandomValues() API, which produces cryptographically strong random bytes. All tokens are generated locally in your browser — nothing is sent to any server. This makes the tool safe for generating test credentials during development.

How Each Token Type Is Generated

Understanding the construction method behind each token type helps you choose the right format for your application and correctly replicate it in your own code.

JWT-like Token

A JSON Web Token has three base64url-encoded sections separated by dots: header.payload.signature. The header encodes {"alg":"HS256","typ":"JWT"}. The payload encodes a JSON object containing a random UUID as the subject (sub), the current Unix timestamp as issued-at (iat), and an expiry (exp) set one hour (3 600 seconds) in the future. The signature is 32 cryptographically random bytes encoded as base64url. Padding characters (=) are stripped and +// are replaced with -/_ to produce URL-safe output.

Bearer Token

A bearer token is N random bytes (where N is the length you set with the slider, between 16 and 64) encoded as base64url without padding. The output character count is ⌈N × 4 / 3⌉.

Session Token

A session token is N random bytes (16–64, slider-controlled) converted to a lowercase hex string. Each byte becomes exactly two hexadecimal characters, so the output length is always N × 2 characters.

CSRF Token

A CSRF token is always 32 random bytes converted to hex, producing a fixed 64-character string regardless of the length slider.

Refresh Token

A refresh token is always 48 random bytes encoded as base64url, yielding a fixed 64-character output (⌈48 × 4 / 3⌉ = 64).

OAuth-like Token

An OAuth-like access token is 32 random bytes base64-encoded (standard, not URL-safe) and prefixed with ya29. — the format used by Google OAuth 2.0 access tokens.

Token Output Length Formulas

bearer/refresh: ⌈N × 4/3⌉ chars | session/CSRF: N × 2 chars

Where:

  • N= Number of random bytes used as input
  • ⌈ ⌉= Ceiling function — round up to nearest integer
  • 4/3= Base64 expansion ratio (every 3 bytes → 4 chars)
  • ×2= Hex expansion ratio (every 1 byte → 2 hex digits)

Token Length, Entropy, and Security

The security of a random token is measured in bits of entropy — the number of equally likely possibilities an attacker would have to try. A token made from N random bytes has N × 8 bits of entropy. Because crypto.getRandomValues() is a cryptographically secure pseudo-random number generator (CSPRNG), each byte is statistically independent and uniformly distributed.

Token Type Fixed Bytes Entropy (bits) Output Format
JWT-like 32 (sig) + UUID 256+ header.payload.signature
Bearer (32 bytes) 32 256 Base64url, ~43 chars
Session (32 bytes) 32 256 Hex, 64 chars
CSRF 32 256 Hex, 64 chars
Refresh 48 384 Base64url, 64 chars
OAuth-like 32 256 ya29. + base64, ~48 chars

For most web applications, 128 bits of entropy (16 bytes) is considered the minimum safe threshold. NIST SP 800-63B recommends at least 64 bits for session identifiers but 112 bits or more for tokens used over a network. The default 32-byte setting in this generator provides a comfortable 256-bit security margin — far beyond what any brute-force attack can reach with current hardware.

Common Use Cases for Generated Tokens

Knowing when to reach for each token format saves architectural mistakes and security rework later. Here is a practical guide to each type.

JWT-like Tokens — Stateless APIs

Use JWT-shaped tokens when you need to transmit verifiable claims between services without shared state. They are common in microservice architectures, mobile backends, and single-page application (SPA) APIs. The compact dot-separated format is easy to pass in an Authorization: Bearer HTTP header. Generate a batch during local development to populate fixture files or unit tests without spinning up a real identity provider.

Bearer Tokens — HTTP Authorization Headers

Bearer tokens follow RFC 6750 and are the simplest way to protect an API endpoint. Drop one into Postman, Insomnia, or curl to test protected routes. They are also used as API keys for server-to-server communication — the receiving service simply checks the token against a stored hash.

Session Tokens — Cookie-Based Authentication

Session tokens are stored in a database alongside session data and set as a HttpOnly; Secure; SameSite=Strict cookie. The hex format is database-friendly, indexable, and easy to log without special encoding. Use the 32-byte (64-char) setting for compatibility with most session store libraries.

CSRF Tokens — Form Protection

CSRF tokens are embedded as hidden form fields or custom request headers. The server validates that the submitted token matches the one stored in the user's session. Always 64 characters in this generator, which is consistent with Django, Laravel, and Rails default CSRF token lengths.

Refresh Tokens — Long-Lived Credentials

Refresh tokens are stored securely (often in an encrypted database column) and exchanged for new short-lived access tokens. The longer 48-byte (384-bit) size gives extra security margin for credentials that may be valid for days or weeks.

OAuth-like Tokens — Third-Party Authorization

The ya29.-prefixed format mimics Google's OAuth 2.0 access token structure and is useful for testing OAuth consumer code locally — mock it in your HTTP fixtures so you don't hit rate limits against real authorization servers.

Best Practices and Security Considerations

Tokens generated by this tool are suitable for testing and development only. Before moving to production, follow these security guidelines.

Always use a CSPRNG. This generator uses crypto.getRandomValues() (Web Crypto API), which is cryptographically secure. In production Node.js code, use crypto.randomBytes() from the built-in node:crypto module. Never use Math.random() for security-sensitive values — it is not cryptographically random.

Sign JWT tokens with a real secret. The JWT-like tokens produced here have a random signature, not an HMAC-SHA256 signature over the header and payload. In production, use a library like jsonwebtoken or jose with a proper secret or asymmetric key pair so the token's integrity can be verified.

Store tokens securely. Tokens stored in localStorage are accessible to JavaScript and vulnerable to XSS. For session and refresh tokens, prefer HttpOnly; Secure cookies. For access tokens used in browser SPAs, store them in memory only and refresh on page load.

Set short expiry times. The JWT-like token in this generator sets exp to one hour from generation. In production, short-lived access tokens (5–15 minutes) paired with refresh tokens are the recommended pattern per OAuth 2.0 Security Best Current Practices (RFC 9700).

Rotate and revoke tokens. Implement a token revocation list or use short expiry times so compromised tokens have a limited blast radius. Refresh tokens should be rotated on each use (refresh token rotation).

Worked Examples

Bearer Token — 24 Bytes

Problem:

Generate a bearer token using 24 bytes of random data. What is the expected output length and entropy?

Solution Steps:

  1. 1Set token type to Bearer and move the length slider to 24 bytes.
  2. 2The tool calls crypto.getRandomValues() to fill a Uint8Array of 24 bytes.
  3. 3Those bytes are encoded with btoa() (base64), then padding (=) stripped and +// replaced with -/_.
  4. 4Output length = ⌈24 × 4/3⌉ = ⌈32⌉ = 32 characters.
  5. 5Entropy = 24 × 8 = 192 bits — well above the 128-bit minimum threshold.

Result:

A 32-character base64url string such as 'x7Kp2mNqRvLsWoYeZtBfCjDhAuIgMnOp' with 192 bits of entropy.

Session Token — 16 Bytes

Problem:

Generate a minimum-size session token using 16 bytes. What is the hex output length?

Solution Steps:

  1. 1Set token type to Session and move the length slider to its minimum: 16 bytes.
  2. 2The tool fills a Uint8Array of 16 bytes with crypto.getRandomValues().
  3. 3Each byte is converted to a 2-digit hex string with b.toString(16).padStart(2,'0').
  4. 4Output length = 16 × 2 = 32 hex characters.
  5. 5Entropy = 16 × 8 = 128 bits — the NIST-recommended minimum for network-transmitted tokens.

Result:

A 32-character lowercase hex string such as 'a3f8c1d70e2b954816af30c72e5d8b91' with 128 bits of entropy.

CSRF Token — Fixed 64 Characters

Problem:

Confirm the CSRF token is always exactly 64 characters regardless of the length slider.

Solution Steps:

  1. 1Select the CSRF token type. Note that the length slider is hidden for this type.
  2. 2The code always allocates exactly 32 bytes: new Uint8Array(32).
  3. 3Each byte → 2 hex digits, so output length = 32 × 2 = 64 characters.
  4. 4Changing the slider has no effect on CSRF tokens; the length is hard-coded.
  5. 5Entropy = 32 × 8 = 256 bits — consistent with security frameworks like Django and Rails.

Result:

Always a 64-character hex string, e.g. 'b94c3fa12e5d867c091a4f2b83e6d501c7a90f3e254b18d76e4c92a0f1b3d8e5'.

Refresh Token — Fixed 64 Base64url Characters

Problem:

What is the output length of a refresh token and why is it always the same?

Solution Steps:

  1. 1Select the Refresh token type. The length slider is hidden.
  2. 2The code always uses 48 bytes: new Uint8Array(48).
  3. 348 bytes encoded in base64 = ⌈48 × 4/3⌉ = ⌈64⌉ = 64 characters before stripping padding.
  4. 448 is divisible by 3 (48 / 3 = 16), so no padding characters are produced.
  5. 5Entropy = 48 × 8 = 384 bits — appropriate for long-lived credentials.

Result:

Always a 64-character base64url string with 384 bits of entropy.

Tips & Best Practices

  • ✓Use the Quantity slider to generate a batch of up to 10 tokens in one click — useful for populating test fixture files.
  • ✓For session tokens stored in cookies, choose 32 bytes (64 hex chars) to match the default length expected by most session middleware.
  • ✓JWT-like tokens expire 3 600 seconds (1 hour) from generation time — factor this into any test scenarios that check expiry logic.
  • ✓Never log raw tokens in production systems; log only a short prefix or a hash so you can trace requests without exposing credentials.
  • ✓For unit tests, hard-code a token value in your fixture rather than calling this generator each time — deterministic tests are easier to debug.
  • ✓Refresh tokens should be stored in an encrypted database column, not in a JWT or plaintext column, because they are long-lived.
  • ✓When testing CSRF protection, verify that the server rejects requests where the submitted token does not match the session-stored token.
  • ✓Set the bearer token length to at least 32 bytes (256 bits) for any token that will be used over a public network.

Related Calculators

API Key Generator

Generate random API keys in various formats for securing backend service endpoints.

Bcrypt Generator

Hash passwords and tokens with bcrypt for secure storage in your database.

Checksum Calculator

Compute MD5, SHA-1, and SHA-256 checksums to verify file and data integrity.

Base64 Encoder

Encode arbitrary text or binary data to base64 for use in HTTP headers and data URIs.

Base64 Decoder

Decode base64 strings back to their original text or binary representation.

UUID / Credit Card Validator

Validate token-adjacent identifiers and card numbers during payment integration testing.

Frequently Asked Questions

No. The tokens produced by this generator are intended for testing and development only. JWT-like tokens use a random string as the signature rather than a real HMAC-SHA256 or RSA signature, so they cannot be verified by a JWT library. Bearer and session tokens are random enough to be secure, but production systems need additional infrastructure — secure storage, expiry enforcement, revocation lists, and signed payloads — that this tool does not provide.
The Web Crypto API's <code>crypto.getRandomValues()</code> draws entropy from the operating system's cryptographically secure pseudo-random number generator (CSPRNG) — <code>/dev/urandom</code> on Linux/macOS and <code>BCryptGenRandom</code> on Windows. Unlike <code>Math.random()</code>, which uses a deterministic algorithm seeded at startup, a CSPRNG output is computationally infeasible to predict even if an attacker observes previous outputs. This property is essential for security tokens.
CSRF tokens are fixed at 32 bytes because most security frameworks (Django, Rails, Laravel) expect a 64-character hex CSRF value. Refresh tokens are fixed at 48 bytes to match common OAuth 2.0 library conventions and provide extra entropy for long-lived credentials. OAuth-like tokens mimic a specific real-world format. JWT-like tokens have a structured payload whose size depends on the UUID and timestamp, not a simple byte count. Only bearer and session tokens are format-agnostic enough to benefit from a variable length slider.
NIST SP 800-63B recommends at least 64 bits for secrets transmitted over authenticated channels and at least 112 bits for general-purpose authentication. Most security-conscious developers use 128–256 bits (16–32 random bytes) as the default. This generator's default 32-byte setting provides 256 bits, which is far beyond brute-force reach — even a computer checking a billion tokens per second would need more time than the age of the universe to exhaust all possibilities.
A bearer token is self-contained and opaque — the server may validate it by looking it up in a database or by verifying a cryptographic signature embedded in the token itself. A session token is a pure lookup key: the server receives it, queries a session store, and retrieves the associated session data. Bearer tokens are common in REST APIs and mobile backends; session tokens are traditional in server-rendered web apps that use cookies.
Yes. Use the Quantity slider (range 1–10) to generate up to ten tokens in a single click. Each token in the batch is independently generated from fresh random bytes — they share no common state or entropy pool. You can copy each token individually using the Copy button next to it.
The <code>ya29.</code> prefix is the literal string that Google prepends to its OAuth 2.0 access tokens. This generator mimics that format for developers building integrations with Google APIs who need realistic-looking test tokens for mock HTTP responses. The 32 random bytes following the prefix are base64-encoded (standard alphabet, not URL-safe), matching the general structure of real Google tokens.

Sources & References

Last updated: 2026-06-05

💡

Help us improve!

How would you rate the Token Generator?

<>

Editorial Note

MyCalcBuddy Editorial Team

This page is maintained as an educational calculator reference.

Source

Formula Source: Standard Mathematical References

by Various

UpdatedLast reviewed: May 2026
CheckedFormula checks are based on standard references and internal QA review.