JWT Decoder

Decode a JWT header and payload, and check expiry and standard claims.

API Runs in your browser
Token Not transmitted, not stored

No token decoded yet

Paste a JWT above — a leading “Bearer ” is stripped for you. You will get the header, the claims with their meanings, and the expiry status.

Runs entirely in your browser. Your data isn't uploaded — this page makes no network request with anything you type, which you can verify in your browser's network tab. How this works.

What is the JWT Decoder?

A JSON Web Token is three Base64url segments separated by dots: a header saying how it is signed, a payload of claims, and a signature. The first two are merely encoded, not encrypted — anyone holding the token can read them, which is why decoding one is a routine debugging step rather than an attack.

This decoder splits the token, decodes the header and payload, and interprets the registered claims: when it was issued, when it expires, who issued it and who it is for. Decoding happens entirely in your browser — the token is never sent anywhere, which matters, because a bearer token pasted into a server-side tool is a credential you have just disclosed.

How to use it

  1. Paste the token. A leading "Bearer " prefix is stripped for you.
  2. Read the decoded header to see the algorithm and key ID.
  3. Read the payload, where standard claims are annotated with their meaning and timestamps are rendered as dates.
  4. Check the claim panel for expiry, not-before and issued-at status.

Example

The decoded header and claims of a sample token (signature not shown).

Input
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsxIn0.eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlIiwic3ViIjoidXNlcl8xMjMiLCJleHAiOjE3ODg4MjkyMDB9.…
Result
header   { "alg": "RS256", "kid": "k1" }
payload  { "iss": "https://idp.example", "sub": "user_123", "exp": 1788829200 }

exp  2026-09-08T01:00:00Z — expired

Features

  • Header, payload and signature shown separately
  • exp, nbf and iat rendered as absolute and relative times, with expiry status
  • Plain-language annotation of registered claims (iss, sub, aud, jti, scope)
  • Algorithm warnings, including the "none" algorithm and unexpected symmetric algorithms
  • Malformed token diagnostics that name the failing segment
  • Nothing transmitted, and the token is never written to local storage or history

Frequently asked questions

Does this verify the signature?
No, and that is intentional. Verification needs the issuer's key, and a tool that asks you to paste a signing secret into a web page is teaching a dangerous habit. Verify tokens in your application, against a key you fetched from the issuer's JWKS endpoint.
Is it safe to paste a real token here?
The decoding is local: the page issues no network request with your token, and you can confirm that in your browser's network tab. Even so, treat any unexpired token as a live credential — if you have pasted one into a tool you do not trust, rotate it.
Why can anyone read my JWT payload?
Because a JWS-signed JWT is signed, not encrypted. The signature guarantees integrity, not confidentiality. Never put anything sensitive in a claim; if you must, use JWE.
What does alg: none mean?
An unsigned token. Some libraries historically accepted these, allowing anyone to forge a token by setting the algorithm to none. Any real verifier must reject it, and pin the expected algorithm explicitly.
Why does my token decode correctly but get rejected by the API?
Check exp against the server's clock, then aud and iss — a token minted for a different audience or by a different tenant decodes perfectly and still fails verification.
Esc

Loading the catalog…