Paste a JSON Web Token to inspect its header, claims, and expiry times. 100% in your browser — your token is never uploaded anywhere.
Your token never leaves this browser.
Decoding happens 100% locally — 0 bytes uploaded to any server. Never paste a production token into a website you don't trust.
Geek check: open DevTools → Network tab — 0 bytes of your data uploaded.
Debugging auth usually starts with the same question: what's actually inside this token? The payload tells you who issued it (iss), who it's for (aud), who it's about (sub), and — most importantly — whether it has already expired (exp). A surprising number of “mysterious 401” bugs turn out to be a token whose exp passed hours ago, or an audience claim that doesn't match the API being called.
The payload of a JWT is only base64url-encoded, not encrypted — anyone holding the token can read it. That's why this page is safe to use offline-style: decoding requires no secrets at all. But the same property means decoding proves nothing about authenticity. Only the party holding the signing key can confirm the signature, and that check must happen on your own server, never by pasting secrets into a third-party site.
JWT (JSON Web Token) is a compact, self-contained way to transmit claims between parties — the standard format for login sessions and API access tokens. It has three base64url-encoded parts separated by dots: the header (signing algorithm), the payload (claims like user ID and expiry), and the signature.
No — and that's by design. Verifying a signature requires the signer's secret key (HMAC) or public key (RSA/ECDSA), and you should never paste a secret key into any website. This tool decodes and displays the token's contents and format; it cannot tell you whether the signature is valid. A token that decodes cleanly is not necessarily a valid token.
Decoding happens entirely in your browser — 0 bytes are uploaded to any server. Still, a JWT can contain sensitive claims (user IDs, emails, roles), so treat it like a password: don't paste production tokens into websites you don't trust, and clear the field when you're done.
They are Unix timestamps: exp (expiration time) — the token must be rejected after this moment; iat (issued at) — when it was created; nbf (not before) — the token is invalid before this moment. This page converts them to your local time and shows relative labels like “expires in 3 hours” or “expired 2 days ago”.
The most common causes: the token was truncated when copied (a JWT has exactly three dot-separated parts), it contains whitespace or line breaks, or it isn't a JWT at all — opaque session tokens and API keys look random and won't decode. Try the sample token to confirm the decoder works.