JWT Decoder

Why pasting a token into a website is a bad habit

A JWT is usually a live credential. It is the thing that proves to an API that you are a particular user with particular permissions, and until it expires, anyone holding it can act as you.

The popular online JWT debuggers post the token to their server to decode it. Most are run by reputable companies with no interest in your session, but the exposure is real and entirely avoidable: the token has crossed a boundary, it has probably been logged somewhere, and in many organisations that is a reportable security event regardless of who received it.

The decoding itself is trivial — split on dots, Base64URL-decode two segments, parse the JSON. There is no reason for it to happen anywhere but in your own browser, which is what this tool does. Open the network tab and watch: nothing is sent.

The habit matters more than any single incident. Engineers debug tokens constantly, and a reflex of pasting production credentials into whatever tool ranks first is worth replacing with one that cannot leak.

What a JWT actually is

Three Base64URL-encoded segments separated by dots. The header declares the signing algorithm. The payload carries the claims — the actual statements about the user. The third segment is the signature.

The critical point, and the most widespread misunderstanding: the header and payload are encoded, not encrypted. Base64URL is a text representation with no key and no secret. Anyone who intercepts a token can read every claim in it in one step.

This means a JWT is the wrong place for anything confidential. Putting a user's role in a token is normal; putting their address, their internal notes or a secondary secret in one is a disclosure waiting to happen. If the payload genuinely needs to be hidden, you need JWE, which is a different specification.

What the signature provides is integrity, not secrecy. It proves the payload has not been altered since the issuer created it. It says nothing about whether the contents are private, because they are not.

The registered claims and what they mean

Seven claims are defined by the specification and appear in most tokens. `iss` is the issuer, `sub` the subject the token is about, and `aud` the intended audience — an API that accepts a token minted for a different audience has a real vulnerability.

`exp`, `nbf` and `iat` are timestamps in Unix seconds, which this tool converts to readable dates. `exp` is when the token stops being valid, `nbf` is a not-before time for tokens issued in advance, and `iat` is when it was created. `jti` is a unique identifier, used to make a token revocable or to prevent replay.

Everything else is a custom claim your system defines. Roles, permissions, tenant identifiers and feature flags all commonly live there, and the payload view shows them exactly as issued.

Expiry is the claim that causes most confusion in practice, because a token that looks fine can be minutes past its lifetime. The badge here tells you immediately, which usually ends the debugging session.

Decoding is not verifying

This tool shows the signature but does not check it, and that is deliberate. Verification requires the issuer's secret — for HMAC algorithms — or its public key. A tool that offered to verify would be asking you to paste your signing secret into a web page, which is a far worse idea than pasting the token.

So treat a decoded payload as a claim, never as proof. The contents tell you what the issuer said, assuming the token is genuine. Anyone can construct a token with any payload they like; only signature verification against a trusted key distinguishes a real one.

This matters for a specific class of bug: application code that decodes a token to read the user's role without verifying the signature. That is a complete authentication bypass, and it is a mistake that has shipped to production more than once. Verify on the server, with a library, against a key you control.