JWT Decoder & Debugger

A JSON Web Token, or JWT, is a compact way to carry claims about a user between a server and a client. You will find them everywhere in modern authentication: after you log in, an application often hands you a JWT that your browser sends back on every request to prove who you are. A token is three base64url-encoded parts joined by dots, and because base64url is just an encoding, this decoder can reveal the contents of the first two parts instantly without any secret. That transparency is the whole point of the tool - and also the source of the most common mistakes people make with tokens.

The three parts of a token

The structure is header.payload.signature. The header is a small JSON object naming the token type and the signing algorithm, for example {"alg":"HS256","typ":"JWT"}. The payload holds the claims - the actual statements about the user and the session. The signature is a cryptographic stamp computed over the header and payload together, and it is what lets a server trust that the first two parts have not been altered. Only the signature depends on a secret; the header and payload are merely encoded.

Header and payload are readable, not encrypted

This is the single most important thing to internalise: the header and payload of a standard JWT are not encrypted. Anyone who holds the token - including this decoder - can read every claim inside it. The signature stops tampering, but it does nothing to hide the contents. That means you must never put a password, an API key, or any other secret into a JWT payload, because doing so is the same as writing it in plain text. Standard claims use short registered names: iss is the issuer, sub is the subject or user, aud is the intended audience, exp is the expiry time, iat is when the token was issued, and nbf is the not-before time before which the token is invalid. The exp, iat and nbf values are Unix timestamps, which is why this tool renders them as ordinary dates.

What the signature is for

The signature exists to answer one question: did someone tamper with this token? The server recomputes it from the header and payload using its secret or private key and compares the result to what arrived. If they differ, the token is rejected. Crucially, this tool deliberately does not verify the signature, because verification requires the server's secret, which you should never have as an outside party. Reading a token and trusting a token are two very different acts, and only the server that holds the key can do the second.

Attacks to study in authorised labs

Because JWTs sit at the heart of authentication, they attract a well-known set of attacks that are worth understanding defensively - and only ever testing against systems you own or have explicit permission to assess. The alg:none attack tries to strip the signature by setting the algorithm to none and hoping the server accepts an unsigned token. Weak-secret attacks brute-force a short or guessable HMAC key offline until a forged token verifies. Algorithm-confusion attacks try to trick a server that expects an RS256 public/private key pair into validating an HS256 token signed with that public key as if it were an HMAC secret. Learning to recognise these patterns is exactly the kind of hands-on skill our labs are built to teach in a safe, sandboxed environment.

A quick worked example

Imagine pasting a token whose middle segment decodes to {"sub":"1234","name":"Ada","iat":1700000000,"exp":1700003600}. You can immediately read that the token belongs to user 1234 named Ada, was issued at the iat timestamp, and expires one hour later at the exp timestamp - which this tool would display as a friendly date so you can tell at a glance whether the token is still valid. Notice how much you learned without any key at all, and let that be the reminder never to trust a JWT to keep a secret.