JWT Decoder

Decode and inspect JSON Web Token headers, payloads, and expiry claims — no verification, fully local.

JWT Decoder

Decode and inspect JSON Web Tokens locally. No verification — decode only.

Paste JWT Token

How to use JWT Decoder

1
Paste your JWT token into the input box.
2
The header, payload, and claims are decoded instantly.
3
Check the Claims Summary for expiry (exp), issued-at (iat), and not-before (nbf).

Frequently Asked Questions

Is it safe to paste a production JWT token here?

All decoding happens locally in your browser — nothing is sent to any server. That said, avoid pasting tokens with sensitive permissions in shared or public computer environments.

Does this tool verify the JWT signature?

No — decoding and verification are different operations. Decoding reads the base64url-encoded payload. Verification checks the cryptographic signature using the secret key, which must be done server-side.

What is the structure of a JWT?

A JWT has three dot-separated parts: Header (algorithm and token type), Payload (claims — user ID, roles, expiry), and Signature (HMAC or RSA hash of header + payload using a secret). Only the payload contains meaningful data for most use cases.

What claims should I look for in the payload?

Key standard claims: exp (expiry timestamp), iat (issued at), nbf (not valid before), sub (subject — usually user ID), iss (issuer). Expired tokens have exp values in the past.

Why does my JWT show "invalid token"?

Common causes: the token is truncated (copy the full string including dots), the token has expired and the tool is flagging the exp claim, or the string contains extra whitespace characters.

Can I put sensitive user data in a JWT payload?

No — JWT payloads are base64url-encoded, not encrypted. Anyone who intercepts the token can read the payload. Never store passwords, credit card numbers, or private personal data in a JWT payload.

Detailed Guide

What's Inside That Token?

A JWT bouncing between your frontend and backend is just a string of three base64-encoded segments. It looks like this:

eyJhcGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEwNDIiLCJuYW1lIjoiQXJ5YW4gU2luZ2giLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MDk0MDM2MDB9.SIGNATURE

To debug authentication failures, verify claims, or audit what data your auth server is embedding — you need to read what's inside. This tool decodes all three segments instantly, renders the claims in a clean readable format, and highlights expiry status automatically. Your token never leaves your device.

JWT Structure: Three Parts

[Header].[Payload].[Signature]

Header — a JSON object declaring the token type and signing algorithm:

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

Payload — a JSON object containing claims about the user or session:

{
  "sub": "user_1042",
  "name": "Aryan Singh",
  "role": "admin",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1709317200,
  "exp": 1709403600
}

Signature — cryptographic proof that the header and payload haven't been tampered with. Computed using a secret key (HMAC) or private key (RSA/ECDSA). Without the secret, the signature can't be verified — and this tool doesn't ask for it.

Both the header and payload are encoded with Base64URL (a URL-safe variant of Base64 that uses - instead of + and _ instead of /). Decoding them reveals the JSON above.

Standard JWT Claims to Know

Claim	Meaning	Format
`sub`	Subject — identifies the user/entity	String (usually an ID)
`iss`	Issuer — who created the token	URL string
`aud`	Audience — intended recipient	String or array
`exp`	Expiration time	Unix timestamp (seconds)
`iat`	Issued At — when token was created	Unix timestamp (seconds)
`nbf`	Not Before — token invalid before this time	Unix timestamp (seconds)
`jti`	JWT ID — unique token identifier	String

This tool automatically converts exp, iat, and nbf from Unix timestamps to human-readable date/time strings, and shows whether the token is expired.