π JWT Decoder
Decode JSON Web Tokens privately, right in your browser.
π Private by design: decoding happens locally. Nothing is uploaded or stored.
How to Use This Decoder
Paste any JWT into the box. The header and payload decode instantly, timestamps become readable dates, and the signature is shown without being verified.
Paste the full token, all three parts including the dots.
Read the header: the alg tells you the signing algorithm, typ confirms it is a JWT.
Read the payload claims. exp, iat, and nbf are translated to human dates with an expired/live verdict.
Remember: decoding is not verifying. Check the signature on your server before trusting claims.
Anatomy of a JWT
The header is JSON describing the token type and signing algorithm. The payload is JSON carrying claims: public ones like iss and exp, plus whatever custom fields the issuer added. Both are Base64url-encoded, which is encoding, not encryption: anyone holding the token can read them. The signature is computed over header.payload with the issuer's secret or private key, and it is the only part that proves authenticity. That is why decoding locally is safe but trusting remotely requires verification.
Registered Claims Cheat Sheet
Debugging OAuth Flows With Decoded Tokens
Most JWT debugging sessions end at one of three findings. First, the token is expired: exp is in the past, so the client needs a refresh-token call. Second, the audience is wrong: aud names a different API than the one rejecting the token, common when staging and production issuers get mixed. Third, the algorithm surprises you: alg "none" in a token your server accepts is a critical vulnerability, and an unexpected RS256/HS256 swap breaks verification. Decoding first, before touching server code, turns a mysterious 401 into a five-minute fix.
Frequently Asked Questions
What is a JWT?
A JSON Web Token is a compact, URL-safe way to pass claims between two parties, most often for authentication. It has three Base64url-encoded parts separated by dots: header, payload, and signature. The header says how it is signed, the payload carries the claims (like user id and expiry), and the signature proves it was issued by someone holding the secret.
What are registered claims?
The JWT spec defines a few standard claim names: iss (issuer), sub (subject, usually the user), aud (audience), exp (expiry time), nbf (not valid before), iat (issued at), and jti (unique token id). This decoder highlights them and translates the timestamp claims into readable dates.
Does decoding verify the signature?
No. Decoding just reads the payload; anyone can decode any JWT. Verification needs the secret or public key and must happen on your server. Never trust claims from a token you have not verified, no matter how official the payload looks.
Why is my token expired?
The exp claim is a Unix timestamp. If it is in the past, the token is expired and servers should reject it. Common causes: a short-lived access token (often 15 to 60 minutes) that was not refreshed, or clock skew between the issuer and the verifier. Check the decoded expiry date against the current time.
Is it safe to paste tokens here?
Yes, for debugging. This page decodes entirely in your browser with JavaScript: the token is never uploaded, logged, or sent anywhere. Still, treat tokens like passwords in general: do not paste production secrets into any website, and revoke a token if you suspect it leaked.