JWT Decoder

What is a JWT?

JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. JWTs are commonly used for authentication and authorization in web applications and APIs.

JWT Structure

A JWT consists of three parts separated by dots:

header.payload.signature

Common JWT Claims

The payload typically contains these standard claims:

Security Considerations

Important: This tool decodes JWTs but does not verify signatures. Anyone can decode a JWT and read its contents — the signature only prevents tampering.

• Never trust a JWT without verifying its signature on your server
• Don't store sensitive data in JWT payloads (they're not encrypted)
• Always check the exp claim to reject expired tokens
• Validate the iss and aud claims match expected values

JWT vs Session Cookies

Working with JWTs in Code

JavaScript

// Decode without verifying (like this tool)
function decodeJWT(token) {
  const payload = token.split('.')[1];
  return JSON.parse(atob(payload));
}

// With a library (recommended for verification)
import jwt from 'jsonwebtoken';
const decoded = jwt.verify(token, secretKey);

Python

import jwt

# Decode without verifying
decoded = jwt.decode(token, options={"verify_signature": False})

# Decode with verification
decoded = jwt.decode(token, secret_key, algorithms=["HS256"])

Related Tools

• Base64 Encode/Decode — Encode or decode Base64 data
• JSON Validator — Validate JSON syntax
• JSON Pretty Print — Format JSON for readability

Frequently Asked Questions

Is it safe to decode a JWT in the browser?

Yes, decoding is safe. JWTs are not encrypted — they're just Base64-encoded. The signature protects against tampering, not reading. Never put sensitive information in a JWT that you wouldn't want users to see.

Why does my JWT show as expired?

The exp claim is a Unix timestamp. If the current time is past this value, the token is expired. Tokens typically expire in minutes to hours for security.

Can I verify the signature with this tool?

No. Signature verification requires the secret key or public key used to sign the token, which should never be shared publicly. Use server-side code to verify signatures.

Common Mistakes & Pro Tips

• Decoding is not verifying — the signature is unchecked — This tool Base64URL-decodes the header and payload so you can read them, but it does not verify the signature against a secret or public key. A decoded token can still be expired, tampered with, or forged; never trust its contents for authorization without verifying the signature server-side.
• A JWT is signed, not encrypted — the payload is public — Anyone holding the token can decode the payload and read every claim; signing only proves integrity, not confidentiality. Never put passwords, secret keys, or sensitive personal data in a JWT payload, because it is effectively plaintext to whoever receives it.
• exp and iat are Unix seconds, not milliseconds — Per RFC 7519, exp, iat, and nbf are NumericDate values — seconds since 1970-01-01 UTC. JavaScript's Date.now() returns milliseconds, so multiply these claims by 1000 before constructing a Date, or you'll compute a timestamp in 1970.
• JWTs use Base64URL, not standard Base64 — The three segments are encoded with the URL-safe alphabet (- and _ instead of + and /) and typically have their = padding stripped. A standard Base64 decoder may fail on a JWT segment, which is why a dedicated decoder handles the padding and alphabet correctly.
• alg: none is a red flag — A header specifying "alg": "none" means the token is unsigned, a historically exploited way to bypass verification. If you see it on a token that's supposed to be authenticated, treat the token as untrusted and reject it on the server.