🔑 JWT Decoder ☆

Overview

JWT Decoder decodes any JSON Web Token straight in your browser. Paste a token and instantly see its three parts: the header (signing algorithm, type, key ID), the payload (all claims as formatted JSON) and the raw signature. Time-based claims are translated into human-readable dates, and the tool tells you whether the token is valid, expired, not yet valid or has no expiration at all. Everything runs client-side. Your token is never uploaded, which matters because JWTs often carry session identifiers and personal data. Note that decoding does not verify the signature: for that you need the secret or public key.

What a JWT contains

A JWT is three base64url segments separated by dots. The header names the signing algorithm and key id; the payload carries claims such as iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at) and nbf (not before); the signature lets a server verify the token was issued by a trusted party and not altered. The decoder shows all three, formats the JSON, humanizes the time claims and reports whether the token is currently valid, expired or not yet active.

Specifications and compatibility

Property	JWT decoder behavior
Input	Any JWS token (header.payload.signature)
Decoded parts	Header, payload claims and raw signature
Time claims	exp, iat, nbf rendered as readable dates with status
Validation status	Valid, expired, not yet valid or no expiration
Signature	Not verified: decoding only
Processing	100% client-side; tokens never uploaded
Cost	Free, no account, unlimited tokens

Privacy: session tokens stay in the browser

A JWT is usually a live credential, pasting it into a server-side decoder would hand over a working session. Everything is decoded locally: nothing is transmitted, stored or logged, and the page works offline. Treat decoded output as sensitive too, since payloads often contain email addresses and identifiers.

Debugging JWTs safely

• Check exp first: most "invalid token" bugs are simple expiry.
• Compare iat and nbf when clocks between services drift.
• Verify aud and iss match what the API expects.
• Remember alg: none or symmetric algorithms need careful server validation.
• Never paste production tokens into tools you do not trust.

Related: browse the developer tools for Base64, hashing and regex testing.

JWT structure, signatures and common mistakes

A JSON Web Token has three parts separated by dots: a header describing the algorithm, a payload carrying the claims, and a signature that lets the receiver verify the first two were not altered. All three are Base64URL encoded, which is encoding, not encryption, anyone holding the token can read the claims, so nothing sensitive belongs in the payload. Decoding is therefore always safe to do locally, while verification requires the secret or public key and must happen on the server. Several mistakes recur in real systems. The alg:none attack takes advantage of libraries that trusted the header and accepted an unsigned token; a correct implementation pins the expected algorithm and rejects anything else. Using HS256, a symmetric algorithm, with a weak or leaked secret is another: the secret must be long and random, and asymmetric algorithms such as RS256 are preferable when many parties must verify but only one may sign. Claim validation is easy to forget: exp and nbf must be checked against the current time, iss and aud must match the expected values, and jti enables revocation when a token is stolen. Tokens are bearer credentials, so they should travel only over HTTPS and be stored where scripts cannot read them if XSS is a concern. Remember that a decoded token proves nothing until the signature is verified. This tool decodes locally and stores nothing.