devtools.codes

JWT Decoder

RUNS LOCALLY

Paste a JSON Web Token to read its header, its claims and exactly when it expires. Decoding happens in this page, so a live session token is never sent anywhere. The signature is shown but never checked: verifying it needs the signing key, and no tool should ask you for that. This page carries no advertising and loads no advertising script.

Your tool input is processed locally in your browser and is not intentionally uploaded to our servers. This page carries no advertising and no third-party advertising script, so pasted credentials are never present on a page with an ad request. Advertising and analytics providers may still process normal page, device, cookie and network information on other pages.

No advertisement

This page has no ad slot at any breakpoint and loads no advertising script.

How to use the JWT Decoder

  1. Paste the token. All three segments, as one line, with no spaces or line breaks in the middle.
  2. Read the header and payload panels. Every claim is shown exactly as it was encoded, unmodified.
  3. Check the expiry line. It gives the absolute UTC time and how long is left, or how long ago it lapsed.
  4. Work through the advisories. Each names what it found and what to change at the issuing or verifying end.

A worked example, and what it shows

The example is a token that expired three days ago, signed with HS256 and carrying a subject, an issuer and two custom claims. It is deliberately a failing token rather than a healthy one, because an expired token is the reason most people open a decoder in the first place.

The expiry line reads EXPIRED with the date it lapsed, and the advisories explain that a 401 from your API is the expected response rather than a bug. A second advisory notes that the custom claims are readable by anyone holding the token, since a JWT is signed rather than encrypted.

Press Example in the workspace above to load it.

Common questions about the JWT Decoder

Does this verify the signature?

No, and that is deliberate. Verifying a signature requires the signing key, and a tool that asks you to paste a secret alongside a token is asking for the two things that together grant access. This decodes and inspects only. Verify in your own application, where the key already lives, and pin the algorithms you accept rather than trusting the token header.

Is it safe to paste a JWT into a website?

Usually not, and the caution is warranted: an unexpired token is a live credential, and most online decoders send it to their server to decode it. This page decodes in your browser and carries no advertising script, so the token is not present on a page making requests to anyone else. If a token has already been pasted somewhere you do not control, treat it as exposed and end the session.

Why does my token work in one place and not another?

Check expiry first, then nbf. A token that is expired or not yet valid is rejected by any correct verifier, and a small nbf gap usually means clock skew between the issuing and verifying machines. After that, check that the audience and issuer claims match what the receiving service expects, since a mismatch produces the same opaque 401.

Can I put sensitive data in custom claims?

No. A JWT is signed, not encrypted, so every claim is readable by anyone holding the token — including the browser it was issued to. Signing protects against modification, not against reading. Keep identifiers and coarse authorisation data in claims, and leave anything confidential on the server behind a lookup.

Does my input leave the browser?

No. Your tool input is processed locally in your browser and is not intentionally uploaded to our servers. Advertising and analytics providers may still process normal page, device, cookie and network information. This page carries no advertising and no third-party advertising script, so pasted credentials are never present on a page with an ad request.

Guides that use this tool

Related tools