JWT Decoder

Details

About this tool

Decodes a JWT into its header, payload and signature, and shows the timestamps as readable dates so you can see at a glance whether the token has expired. The token is never transmitted anywhere.

A JWT is three Base64url-encoded parts joined by dots. The header says which algorithm signed it, the payload carries the claims, and the third part is the signature over the first two. Decoding needs no key at all - the first two parts are encoded, not encrypted - which is the fact people are most often surprised by. Anyone holding a token can read everything in it, so a JWT is not a place to put anything the bearer should not see.

The claims worth checking are mostly the registered ones, and they are all timestamps or identifiers: exp is when it expires, iat when it was issued, nbf the earliest moment it is valid, iss who issued it, aud who it is for, and sub who it is about. Times are Unix seconds, which is why an expiry is a ten-digit number rather than a date, and why this page prints both. A token that looks broken has usually just expired, or is being sent to an audience it was not issued for.

What decoding cannot tell you is whether the token is genuine. That takes the signing key and a verification step on your server - and it is the step that matters, because without it a token is a claim rather than proof. The classic attack changes the header algorithm to "none" and strips the signature; a library that trusts the header rather than the expected algorithm will accept it.

This tool decodes only, and does so entirely in your browser. That is not a detail: a JWT is usually a live credential, and pasting one into a site that posts it to a server hands over a working session. An automated test fails the build if any network request from this page contains the token.

Good to know

Questions people actually ask

Is my token sent anywhere?

No. Decoding happens entirely in your browser and the token never appears in a network request. That is verified by an automated test which fails the build if any request from this page carries it - a guarantee worth having, because a JWT is usually a working credential and pasting one into the wrong site is the same as handing over the session.

Does this verify the signature?

No. Verifying requires the signing key, and sending a signing key to a website would be a worse idea than sending the token. This tool decodes and displays; verification belongs on your server, using a library and the expected algorithm.

Is the payload encrypted?

No - it is Base64url-encoded, which anyone can reverse without a key. The signature stops the token being altered; it does not stop it being read. Never put anything in a JWT that the person holding it should not see: internal identifiers and roles are fine, personal data and secrets are not.

What do exp, iat and nbf mean?

Expiry, issued-at and not-before, all as Unix timestamps in seconds. exp is the moment the token stops being accepted, iat when it was created, and nbf the earliest moment it may be used. This page shows each as a readable date, because a ten-digit number is not something anyone should have to convert in their head while debugging.

What is the "alg: none" attack?

A forged token with its header algorithm set to "none" and its signature removed. A verifier that reads the algorithm out of the header - rather than insisting on the one it expects - will conclude that no signature was required and accept it. Always pin the algorithm on the verifying side; reputable libraries now refuse "none" by default, but older code and hand-rolled checks still get this wrong.