JWT Decoder

JWT Structure

A JSON Web Token (RFC 7519) consists of three Base64url-encoded segments separated by dots: header.payload.signature. Base64url is a variant of Base64 that replaces + with - and / with _, and omits padding, making the token safe to use in URLs and HTTP headers without further encoding.

Header and Payload Fields

The header declares the signing algorithm (alg) and token type (typ). Common algorithm values: HS256 uses HMAC-SHA256 with a shared secret — fast but both parties must know the secret. RS256 uses RSA with a private/public key pair — the server signs with the private key and clients verify with the public key, which can be published openly. ES256 uses ECDSA and is more compact than RSA.

The payload carries claims. Registered claim names are standardised: iss (issuer), sub (subject — typically a user ID), aud (audience — intended recipient), exp (expiration time), iat (issued at), and nbf (not before). All time values are Unix epoch timestamps — seconds since 1 January 1970 UTC. Private claims are any additional key–value pairs the application needs to carry.

Signatures and Verification

The signature is computed over Base64url(header) + "." + Base64url(payload) using the algorithm declared in the header. Tampering with any part of the token — even changing a single character in the payload — invalidates the signature. This decoder reveals the header and payload contents without verifying the signature, which requires the secret key or public key to be present server-side.

Security Considerations

Because the payload is only encoded (not encrypted), any party who intercepts a JWT can read its claims. Never store sensitive information such as passwords, credit card numbers, or private keys in a JWT payload. If confidentiality is required, use JWE (JSON Web Encryption) instead. Also be aware of the "none" algorithm attack — a malicious client can forge a token with alg: "none" and no signature if a server library naively trusts the header. Always specify and enforce expected algorithms on the receiving end.

Worked Examples

Example 1: Decoding a typical access token

A token like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ.<sig> splits on the dots into three segments. Decoding the first gives {"alg":"HS256","typ":"JWT"} — signed with HMAC-SHA256. The second yields {"sub":"12345","name":"Alice","iat":1700000000,"exp":1700003600} — subject "12345", issued at 22:13 UTC 14 Nov 2023, expires 1 hour later. The third segment is the signature; this tool does not verify it.

Example 2: Checking token expiry

To see whether a token is still valid, compare its exp claim to the current Unix timestamp. If exp = 1700003600 and Math.floor(Date.now() / 1000) = 1700004000, the token expired 400 seconds ago (6 minutes and 40 seconds). Most APIs respond with 401 Unauthorized and expect the client to refresh using a separate, longer-lived refresh token.

Example 3: Reading a Google-issued ID token

Google OAuth 2.0 ID tokens are RS256-signed JWTs with claims like iss: "https://accounts.google.com", aud: "<your-client-id>", email, and email_verified. After decoding, verify that iss matches Google, aud matches your app's client ID, and exp is in the future. Use the public keys at https://www.googleapis.com/oauth2/v3/certs to validate the signature — do not trust claims without that validation.

Example 4: Spotting a tampered token

Change one character in the encoded payload — e.g., flip a single "0" to "1" — and the signature no longer matches. A properly configured server rejects the tampered token with a 401. If tampering is undetected, the application has a bug in its verification code (often using jwt.decode instead of jwt.verify). Always use the verify method in production.

Common Pitfalls

• Storing JWTs in localStorage. Any XSS vulnerability leaks the token. Prefer httpOnly cookies with SameSite attributes, or short-lived tokens combined with refresh tokens.
• Trusting the alg header blindly. A malicious client can set alg: "none" and remove the signature; naive server libraries accept this as valid. Hard-code the expected algorithm in your verify call.
• Treating the payload as encrypted. JWTs are signed, not encrypted — anyone with the token can read the claims. For confidential data, use JWE (JSON Web Encryption).
• Long-lived tokens. If a JWT is valid for days, there is no built-in revocation until it expires. Keep access tokens short (5–60 minutes) and rely on refresh tokens for longer sessions.
• Ignoring clock skew. Server and client clocks may disagree by a few seconds. Allow a small leeway (30 seconds) when comparing exp and nbf to avoid spurious rejections.

Frequently Asked Questions

Is a JWT the same as an API key?

No. An API key is a static string granted to a client, typically long-lived and revocable on the server. A JWT is a self-contained signed claim set — the server does not need to look up the token in a database to trust it. JWTs excel at stateless authentication; API keys remain common for server-to-server integrations where state lookups are cheap.

What is the difference between JWT, JWS, and JWE?

JWS (JSON Web Signature) is the structure for signed tokens — header, payload, signature. JWT (RFC 7519) specifies the claim set that typically rides inside a JWS. JWE (RFC 7516) is the encrypted counterpart: five Base64url segments separated by dots, where the payload is encrypted rather than merely signed. Most people saying "JWT" mean "JWS carrying a JWT claim set".

Why are my JWT tokens so large?

JWTs add ~200 bytes of Base64 overhead plus your claims. A signed RS256 token with an iss, sub, aud, exp, iat, and a dozen role claims easily reaches 800–1200 bytes — enough to matter on high-volume mobile APIs. Trim custom claims, use opaque tokens with a lookup table, or switch to shorter session IDs when token size becomes a bandwidth concern.

Can I revoke a JWT before it expires?

Not without storing state. JWTs are stateless by design — the signature is the only trust signal. To revoke, either (a) keep a denylist of revoked token IDs (using the jti claim), (b) issue very short-lived tokens so natural expiry is fast, or (c) rotate the signing key, which invalidates every outstanding token at once.

Should I use HS256 or RS256?

HS256 uses a single shared secret and is simpler — suitable when the issuer and verifier are the same service. RS256 uses a private/public key pair — required when you need multiple independent verifiers (microservices, third-party consumers) that should not hold the signing key. Most large-scale systems standardise on RS256.

Related Calculators

• → Base64 Encoder / Decoder — JWTs are three Base64URL segments.
• → Unix Timestamp Converter — convert iat and exp claims to dates.
• → JSON Formatter — inspect the decoded payload object.
• → URL Encoder — tokens ride in URL query parameters.

View all Developer Tools →

Disclaimer

This calculator is provided for educational and informational purposes only. While we strive for accuracy, users should verify all calculations independently. We are not responsible for any errors, omissions, or damages arising from the use of this calculator.