MyCalcBuddy

JWT Generator

Generate JSON Web Tokens (JWT) for testing and development purposes.

Configuration

Payload (Claims)

Add Standard Claims:

Generated JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTc4NDI3MDU5OCwiZXhwIjoxNzg0Mjc0MTk4fQ.eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHgzZjM0ZjA4Mg

Decoded Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Decoded Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1784270598,
  "exp": 1784274198
}

Warning: This tool is for testing purposes only. The signature is simulated and not cryptographically secure. Never use these tokens in production.

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Defined in RFC 7519, the JWT standard has become the dominant mechanism for stateless authentication and authorization in modern web APIs, microservices, and single-page applications.

Unlike traditional session cookies that require server-side storage, a JWT encodes all necessary information directly into the token itself. The server can verify a token's authenticity and extract user data without ever querying a database — making JWTs especially attractive for distributed systems and serverless architectures where maintaining shared session state is impractical.

A JWT is digitally signed, meaning any tampering with its contents will invalidate the signature. The receiving party can detect modifications instantly, giving JWTs a strong integrity guarantee. However, it is important to understand that the default JWT payload is only Base64URL-encoded, not encrypted — anyone holding the token can decode and read the claims. If you need confidentiality, you must use a JWE (JSON Web Encryption) wrapper on top.

JWTs are used extensively in OAuth 2.0 and OpenID Connect flows as access tokens and ID tokens. They are also common in API authentication where clients present the token in an Authorization: Bearer <token> HTTP header. This free online JWT generator calculator lets you create sample tokens instantly for testing, development, and learning purposes, with configurable algorithm, secret key, payload claims, and expiration time.

JWT Structure: Header, Payload, and Signature

Every JSON Web Token consists of exactly three dot-separated parts, each independently Base64URL-encoded:

  • Header — a JSON object declaring the token type (typ: "JWT") and the signing algorithm (e.g., alg: "HS256").
  • Payload — a JSON object containing the claims: facts about the user or session such as subject ID, issuer, audience, expiration time, and any custom data.
  • Signature — a cryptographic value computed over the encoded header and payload using the chosen algorithm and secret key, ensuring the token has not been tampered with.

The three parts are concatenated with periods: encodedHeader.encodedPayload.encodedSignature. The Base64URL encoding converts each JSON object into a compact, URL-safe string by replacing + with -, / with _, and stripping trailing = padding characters. This makes JWTs safe to pass in HTTP headers, query strings, and URL fragments without additional percent-encoding.

This JWT generator tool encodes the header and payload using the browser-native btoa(unescape(encodeURIComponent(str))) pipeline, which correctly handles Unicode characters, then applies the +→-, /→_, and =-strip transformations to produce a standards-compliant Base64URL string.

JWT Token Construction Formula

token = base64url(header) + '.' + base64url(payload) + '.' + base64url(signature)

Where:

  • header= JSON object: { alg: algorithm, typ: 'JWT' }
  • payload= JSON object containing all claims (sub, iat, exp, custom fields)
  • signature= Cryptographic value over encodedHeader + '.' + encodedPayload using the secret key and chosen algorithm
  • base64url(x)= btoa(unescape(encodeURIComponent(JSON.stringify(x)))), then replace '+' with '-', '/' with '_', remove trailing '='

Standard JWT Claims Reference

The JWT specification defines a set of registered claim names in the IANA JSON Web Token Claims Registry. While none are technically mandatory, following these conventions ensures interoperability with any standards-compliant library or service. This JWT generator lets you add the five most common standard claims with a single click.

Claim Full Name Type Description
iss Issuer String / URI Identifies the principal that issued the token, typically the authentication server URL.
sub Subject String Identifies the principal that is the subject of the JWT — usually a user ID or account identifier.
aud Audience String / Array Specifies the recipients the token is intended for. Services must reject tokens where they are not in the audience.
exp Expiration Time NumericDate Unix timestamp (seconds) after which the token MUST NOT be accepted. Calculated as current time + expiresIn × secondsPerUnit.
iat Issued At NumericDate Unix timestamp when the token was generated. Allows relying parties to assess the age of the token.
nbf Not Before NumericDate Unix timestamp before which the token MUST NOT be accepted — useful for scheduling future-dated tokens.
jti JWT ID String A unique identifier for the token, used to prevent replay attacks when combined with a server-side denylist.

Beyond these registered claims, you can include any arbitrary private claims or public claims in the payload — for example, user roles, plan tier, tenant ID, or permissions scopes. Custom claim keys should be namespaced to avoid collisions, typically using a URI or a registered prefix.

How Expiration Time Is Calculated

The exp claim is a NumericDate: a JSON numeric value representing the number of seconds from the Unix epoch (January 1, 1970 00:00:00 UTC). This calculator computes the expiration timestamp using the exact formula from the page's source:

exp = Math.floor(Date.now() / 1000) + (expiresIn × secondsPerUnit)

Where secondsPerUnit resolves as follows:

Unit Seconds per unit Example: expiresIn = 2
Minutes60iat + 120 s (2 minutes)
Hours3,600iat + 7,200 s (2 hours)
Days86,400iat + 172,800 s (2 days)
Weeks604,800iat + 1,209,600 s (2 weeks)

Math.floor(Date.now() / 1000) converts the current millisecond-precision JavaScript timestamp to whole seconds, matching the NumericDate format required by RFC 7519. The resulting exp value is embedded directly into the payload JSON before Base64URL encoding, so the token already carries its own expiry information — no server-side lookup needed to determine validity.

Choosing an appropriate expiration window is one of the most consequential security decisions in JWT-based systems. Short-lived tokens (15 minutes to 1 hour) minimize the window of opportunity if a token is stolen, at the cost of requiring more frequent re-authentication or refresh token cycles. Long-lived tokens (days or weeks) are convenient for mobile apps or offline scenarios but dramatically increase the blast radius of a credential leak.

Signing Algorithms: HMAC vs. RSA

The alg header parameter tells the receiving party which algorithm was used to sign the token. Choosing the right algorithm depends on your trust model and key management capabilities. This JWT generator supports the six most widely deployed signing algorithms.

HMAC Algorithms (HS256 / HS384 / HS512)

HMAC (Hash-based Message Authentication Code) is a symmetric algorithm — the same secret key is used to both sign and verify the token. The number suffix indicates the SHA hash length: HS256 uses SHA-256 (256-bit output), HS384 uses SHA-384, and HS512 uses SHA-512. Longer hash lengths provide stronger collision resistance but produce slightly larger signatures.

HMAC JWTs are the simplest to implement and perform extremely well, but require every service that verifies the token to also hold the secret key. This is fine for monolithic applications or tightly controlled microservice clusters, but problematic in multi-tenant or third-party scenarios where sharing a private secret is undesirable.

RSA Algorithms (RS256 / RS384 / RS512)

RSA is an asymmetric algorithm. The token is signed with a private key and verified with the corresponding public key. This allows you to publish the public key (via a JWKS endpoint, for example) so that any third-party service can verify your tokens without ever seeing the signing key. RS256 is the most common choice in OAuth 2.0 and OpenID Connect deployments.

RSA operations are computationally heavier than HMAC, and key management is more complex — you must securely generate, store, rotate, and distribute key pairs. For most internal APIs, HS256 with a strong secret is entirely sufficient. For federated identity, public API ecosystems, or microservices that span organizational boundaries, RS256 or RS512 is the recommended approach.

Note: This online JWT generator uses a simulated signature for demonstration purposes. The token structure and claim encoding follow the JWT specification exactly, but the cryptographic signature is a fast hash simulation — suitable for exploring token structure and learning, but not for production authentication systems.

JWT Security Best Practices

JWTs are powerful but introduce specific security risks if implemented carelessly. Understanding these pitfalls is essential for any developer building authentication systems. The following best practices reflect current industry guidance from OWASP and the JWT specification authors.

  • Always validate the signature. Never skip signature verification, even for internal services. Libraries that accept the alg: "none" header must explicitly disallow it.
  • Verify the exp claim. Check expiration on every request. A token that was valid yesterday may belong to a terminated account or compromised session today.
  • Check aud and iss. A token issued by your login service should be rejected by an unintended third-party API — always validate the intended audience and issuer on receipt.
  • Use short expiration windows for sensitive operations. Access tokens for financial or admin operations should expire in minutes, not hours. Use refresh tokens for session continuity.
  • Never store sensitive data in the payload. The payload is Base64URL-encoded, not encrypted. Anyone with the token can decode and read every claim — store only the minimum necessary identifiers.
  • Use strong, randomly generated secrets. For HS256, use at least 256 bits of entropy. Weak secrets are trivially brute-forced against intercepted tokens.
  • Rotate secrets and key pairs regularly. Implement key versioning so old tokens can be gradually phased out without a hard cutover.
  • Implement token revocation for high-risk scenarios. JWTs are stateless by design, but a server-side denylist keyed on jti allows forced logout and breach response.

Following these guidelines ensures that your JWT implementation delivers on its promise of stateless, scalable authentication without introducing avoidable vulnerabilities into your application.

Worked Examples

Standard User Authentication Token (1 Hour)

Problem:

Generate a JWT for user ID 42 authenticated via HS256 with a 1-hour expiration. Current Unix time (iat) = 1717603200.

Solution Steps:

  1. 1Set algorithm = HS256, secret = 'my-super-secret-key', expiresIn = 1, unit = hours.
  2. 2Compute exp: secondsPerUnit for 'hours' = 3600. exp = 1717603200 + (1 × 3600) = 1717606800.
  3. 3Build payload JSON: { sub: '42', name: 'Alice', iat: 1717603200, exp: 1717606800 }.
  4. 4Base64URL-encode header { alg: 'HS256', typ: 'JWT' } → 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9'.
  5. 5Base64URL-encode the payload object to produce the second segment.
  6. 6Concatenate: encodedHeader + '.' + encodedPayload + '.' + signature to form the complete three-part JWT.

Result:

A dot-separated JWT valid for exactly 3,600 seconds (1 hour) from issuance, identifying subject '42' with the HS256 algorithm.

API Service Token (24 Hours)

Problem:

Create a server-to-server JWT valid for 24 hours for an internal reporting microservice. iat = 1717603200.

Solution Steps:

  1. 1Set algorithm = HS512 (stronger hash for server-side use), expiresIn = 24, unit = hours.
  2. 2Compute exp: secondsPerUnit = 3600 (hours). exp = 1717603200 + (24 × 3600) = 1717603200 + 86400 = 1717689600.
  3. 3Build payload: { iss: 'https://auth.example.com', sub: 'reporting-service', aud: 'https://api.example.com', iat: 1717603200, exp: 1717689600 }.
  4. 4Add the 'iss' and 'aud' claims using the quick-add buttons on the generator.
  5. 5Base64URL-encode both the header and the enriched payload.
  6. 6Combine into the final JWT: the token will be valid until Unix timestamp 1717689600 (86,400 seconds from now).

Result:

A 24-hour service-to-service JWT with issuer, audience, and expiration claims set, using HS512 for stronger signature integrity.

Short-Lived Password Reset Token (30 Minutes)

Problem:

Generate a JWT for a one-time password reset link that expires in 30 minutes. iat = 1717603200.

Solution Steps:

  1. 1Set algorithm = HS256, expiresIn = 30, unit = minutes.
  2. 2Compute exp: secondsPerUnit for 'minutes' = 60. exp = 1717603200 + (30 × 60) = 1717603200 + 1800 = 1717605000.
  3. 3Build payload: { sub: 'user_789', purpose: 'password_reset', jti: 'abc123xyz', iat: 1717603200, exp: 1717605000 }.
  4. 4Add the 'jti' claim using the quick-add button to enable server-side one-time-use enforcement.
  5. 5Base64URL-encode header and payload; combine with simulated signature to produce the token.
  6. 6The resulting JWT can be embedded in a password reset email link and will automatically be rejected after 30 minutes.

Result:

A 30-minute single-use JWT (exp = iat + 1800) with a unique jti for replay-attack prevention — suitable for transactional email workflows.

Multi-Week Refresh Token (2 Weeks)

Problem:

Create a long-lived refresh token for a mobile app that stays logged in for 2 weeks. iat = 1717603200.

Solution Steps:

  1. 1Set algorithm = HS256, expiresIn = 2, unit = weeks.
  2. 2Compute exp: secondsPerUnit for 'weeks' = 604800. exp = 1717603200 + (2 × 604800) = 1717603200 + 1209600 = 1718812800.
  3. 3Build payload: { sub: 'mobile_user_001', type: 'refresh', iat: 1717603200, exp: 1718812800 }.
  4. 4Use a separate, stronger secret for refresh tokens than for access tokens to limit blast radius.
  5. 5Base64URL-encode header and payload; append the signature segment.
  6. 6Store the refresh token securely on the device (e.g., iOS Keychain / Android Keystore) — never in localStorage.

Result:

A 14-day refresh JWT (exp = iat + 1,209,600 seconds) suitable for mobile session persistence with proper secure storage.

Tips & Best Practices

  • ✓Use the quick-add claim buttons to inject standard RFC 7519 claims (iss, sub, aud, jti, nbf) into your payload without typing JSON manually.
  • ✓Always set an explicit 'exp' claim on tokens used in authentication — tokens without expiration are valid indefinitely if compromised.
  • ✓For microservice architectures, include a scopes or roles array in the payload so downstream services can enforce fine-grained authorization without a database lookup.
  • ✓Use RS256 when third-party services need to verify your tokens — publish your public key as a JWKS endpoint so consumers can fetch and cache it automatically.
  • ✓The 'jti' claim should be a randomly generated UUID or alphanumeric string; combine it with a server-side denylist to implement true one-time-use tokens.
  • ✓Keep JWT secrets at least 256 bits long and randomly generated — dictionary words or short phrases are trivially brute-forced using offline attacks against intercepted tokens.
  • ✓Paste your generated token into jwt.io to visually inspect the decoded header and payload, and verify the structure matches your expectations before embedding it in tests.
  • ✓For password reset, email verification, or magic-link flows, always set a short expiration (5–30 minutes) and enforce single-use via the jti claim.
  • ✓Test token expiration edge cases by generating a token with a 1-minute window and confirming your API returns 401 once the exp timestamp passes.
  • ✓Avoid including personally identifiable information (PII) such as email addresses or phone numbers in JWT payloads unless the channel is encrypted end-to-end with HTTPS.

Related Calculators

API Key Generator

Generate secure random API keys and tokens for authentication and service integration.

Bcrypt Generator

Hash passwords with the bcrypt algorithm — the industry standard for secure credential storage.

Base64 Encoder

Encode any string or binary data to Base64 — the building block behind JWT's payload encoding.

Base64 Decoder

Decode Base64-encoded strings back to plain text, useful for inspecting raw JWT header and payload segments.

Checksum Calculator

Compute MD5, SHA-1, SHA-256, and other cryptographic hashes to verify data integrity.

CRON Expression Parser

Parse and validate CRON expressions for scheduling token refresh jobs and session cleanup tasks.

Frequently Asked Questions

No — this tool is strictly for testing and educational purposes. The signature computation is a simulated hash, not a real HMAC-SHA or RSA operation, so the tokens it produces cannot be cryptographically verified by any standard JWT library. For production use, rely on server-side libraries such as jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java) that implement the full HMAC or RSA signing algorithms securely.
The three-part dot-separated structure is the defining characteristic of a JWT as specified in RFC 7519. The first segment is the Base64URL-encoded header (algorithm and token type), the second is the Base64URL-encoded payload (claims), and the third is the Base64URL-encoded signature. Each part is independently decodable — you can paste any JWT into jwt.io to inspect its contents without needing the secret key.
HS256 (HMAC-SHA256) is symmetric: the same secret is used to sign and verify, making it simple and fast but requiring all verifying parties to share the secret. RS256 (RSA-SHA256) is asymmetric: a private key signs the token and a published public key verifies it, so third-party services can verify tokens without accessing your secrets. Use HS256 for controlled internal systems and RS256 for public APIs, federated identity, or any scenario where token consumers should not hold your signing key.
Yes. The header and payload sections of a standard JWT are only Base64URL-encoded, not encrypted. Any party who obtains the token can decode it and read all claims in plain text. This is by design — JWTs are meant to be transparent to intermediaries while remaining tamper-proof. Never include passwords, credit card numbers, or other sensitive personal data in JWT claims. If confidentiality is required, use JSON Web Encryption (JWE) as defined in RFC 7516.
It depends on the token's purpose and the sensitivity of the resource it protects. Access tokens for regular API calls typically expire in 15 minutes to 1 hour to limit exposure if stolen. Refresh tokens used to obtain new access tokens may last days or weeks but should be stored securely and rotated on each use. Tokens for high-risk operations such as password resets or payment confirmations should expire in 5–30 minutes. The shorter the window, the smaller the attack surface if a token is intercepted.
Base64URL is a variant of standard Base64 that replaces the characters '+' with '-' and '/' with '_', and omits trailing '=' padding. These changes make the encoded string safe to use in URLs, HTTP headers, and query strings without percent-encoding. JWT uses Base64URL for all three segments so that the complete token — including the dots — is a single URL-safe string. This calculator applies the transformation via: btoa(unescape(encodeURIComponent(json))) followed by the character replacements and padding removal.
The 'iat' (Issued At) claim is a NumericDate — a Unix timestamp in whole seconds — recording exactly when the JWT was created. Servers can use it to calculate the token's age, enforce maximum token lifetimes independent of the exp claim, and detect tokens that were issued suspiciously far in the future or past. This generator automatically adds iat = Math.floor(Date.now() / 1000) if the field is not already present in your payload JSON.

Sources & References

Last updated: 2026-06-05

💡

Help us improve!

How would you rate the JWT 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.