JWT Decode
Decodes a JSON Web Token's header and payload, presenting every claim in readable form.
What a JWT is
JSON Web Token (JWT, RFC 7519) is a compact format for transmitting information between two parties as a JSON object, digitally signed. It's the most widely used format today for authentication and claim exchange between services — a server issues the token after login, and every following request sends it to prove identity.
Structure: header.payload.signature
A JWT is always three dot-separated segments, each Base64URL-encoded: the header (signing algorithm and type), the payload (the claims — the actual data) and the signature (proves header and payload weren't altered since issuance, when a trusted verifier checks it).
Registered claims
RFC 7519 defines a small set of standard claims, all optional: iss (issuer), sub (subject/token owner), aud (intended audience), exp (expiration date), nbf (not valid before), iat (issued-at date) and jti (unique token identifier). Any other claim in the payload is specific to the application that issued the token.
Why this tool doesn't verify the signature
Decoding a JWT (reading header and payload) requires no secret at all — it's just Base64URL. Verifying the signature, on the other hand, requires the key used to sign it (a secret, for HMAC, or a public key, for RSA/ECDSA). This tool decodes the content for reading and debugging; it doesn't claim a token is authentic, only that its structure and claims are what appear in the payload.
The "alg: none" attack
One of the best-known attacks against JWT implementations: the attacker takes a valid token, swaps the header for {"alg":"none"} and empties the signature. Old or misconfigured libraries that trust the algorithm declared by the token itself, instead of requiring an expected algorithm, accept the forged payload without any verification. This tool flags that header explicitly, but the real defense is the server-side verifier never trusting the token's "alg".
Frequently asked questions
No. All decoding happens in your browser — the token you paste here never travels over the internet and is never logged anywhere.
No. This is a decoding tool, not a verification one — it shows the content of the header and payload, but doesn't confirm the signature matches any key. A token that "decodes successfully" here doesn't mean it's authentic.
The most common causes are: the token doesn't have exactly 3 dot-separated segments, a segment isn't valid Base64URL, or the decoded content isn't valid JSON. Paste the complete token, without spaces or line breaks in the middle.
It means the payload's exp claim (expiration date) is already in the past relative to your device's current time — it has no relation to whether the signature is correct or not.