JWT Decoder

One input per line. Output is numbered to match the input order.
Pinned tools are listed in your favourites on the home page.Copies a link to this tool that carries your current input, so it opens ready to run.Gives you an iframe snippet for putting this tool on your own site.
Ctrl+Enter Run  · Ctrl+Shift+C Copy  · Esc Clear

Understand JWT Decoder

Decodes the header and payload of a JSON Web Token so you can read its claims, algorithm, and expiry.

How it works

A JWT is three Base64URL segments joined by dots: header, payload, signature. The first two are encoded, not encrypted, which is why reading them needs no key at all — this tool Base64URL-decodes them, parses the JSON, and compares the exp claim against the current time to flag expiry. The signature segment is displayed verbatim and is never checked against anything, so nothing you paste is sent anywhere and no secret is required.

When to use it

  • Reading sub, scope, aud, and iss out of a bearer token that an API is rejecting with a 401 or 403.
  • Telling an expired token apart from one that is merely missing a claim your service requires.
  • Checking which alg and kid an identity provider used, before wiring up verification against its JWKS.
  • Confirming that a login flow issued the claims your authorization rules actually read.
  • Inspecting a token captured in a browser network tab while tracing a permissions bug.

Watch out for

  • Decoding is not verification, and a decoded token is not a trusted one. Anyone can edit a payload, re-encode it, and produce something that decodes perfectly here. Only checking the signature against the issuer key makes a claim worth acting on.
  • Never let a server trust the alg field in the token. Choosing the verification algorithm from the header is what enables the alg: none attack and the RS256-to-HS256 downgrade, where an attacker signs with the public key as an HMAC secret. Pin the expected algorithm and key in your verification code.
  • The payload is readable by everyone who holds the token, including the end user. Signing protects a claim from being altered; it does nothing to hide it. Keep secrets, internal ids, and personal data out of it.
  • exp, iat, and nbf are seconds since the epoch, not milliseconds. A JavaScript Date.now() value in exp puts the expiry tens of thousands of years out, and every conforming verifier will accept it.

Not the right tool for: Deciding whether a request is authorized. That requires verifying the signature and the claims server-side against the issuer key; this is a debugging aid for reading what a token says.

Frequently Asked Questions

Is JWT decoding the same as JWT verification?

No. Decoding reads the Base64URL-encoded contents. Verification checks the signature against a secret key. You can decode any JWT without the key, but you should always verify in production.

What is in the JWT payload?

Common payload claims include sub (subject/user ID), iat (issued at), exp (expiration time), aud (audience), and iss (issuer). Custom claims can be anything.

What does the exp claim mean?

The exp claim is a Unix timestamp indicating when the token expires. This tool shows whether the token is currently valid or expired based on exp.

How to Use JWT Decoder

  1. Paste or type your input in the input area above.
  2. The tool processes your input automatically or click Run.
  3. Copy or download the result using the action buttons.
  4. Use Ctrl+Enter to run quickly from the keyboard.