MinifyPic

JWT Decoder

Decode a JSON Web Token's header and payload, inspect its claims, and check whether it has expired — entirely in your browser.

FreeNo uploadClaims & expiry
Loading tool…

How it works

A compact workflow from input to download.

1

Paste your token

Paste the JWT — the long three-part string separated by dots.

2

Read the parts

The header and payload are decoded and displayed as formatted JSON, with the standard claims explained.

3

Check the expiry

The expiry claim is converted from a Unix timestamp into a readable date so you can see if the token is still valid.

Frequently asked questions

Is it safe to paste my token here?
Here, yes — the decoding runs entirely in your browser and the token never leaves your device. Be aware that this is emphatically not true of every JWT decoder on the web: pasting a live production token into a site that sends it to a server is handing over a valid credential. Treat a JWT exactly as you would treat a password.
Does this verify the signature?
No. Decoding shows you what a token claims; verifying proves those claims have not been tampered with, and that requires the secret or public key that signed it. Decoding is for inspection and debugging. Verification must always happen on your server, with the key, on every request.
Is the payload encrypted?
No — and this surprises people constantly. A standard JWT's payload is merely Base64-encoded, which means anyone holding the token can read every claim inside it. The signature guarantees the payload has not been altered; it does nothing to keep it secret. Never put anything confidential in a JWT payload.
What do exp, iat and sub mean?
They are registered claims with standard meanings: 'exp' is the expiry time as a Unix timestamp, after which the token must be rejected; 'iat' is when it was issued; 'sub' is the subject, usually the user ID; 'iss' is the issuer; and 'aud' is the intended audience.

The three parts of a token

A JWT is three Base64-encoded segments joined by dots, and each has a distinct job. The header declares which signing algorithm was used. The payload carries the claims — who the user is, when the token expires, what they are permitted to do. The signature is a cryptographic hash of the first two parts computed with a secret key, and it is what makes the whole thing trustworthy: change so much as one character of the payload and the signature no longer matches, so the server rejects it. That is the elegance of the design. The server does not need to store the token or look it up in a database; it can verify the token's integrity mathematically from the token itself, which is what makes JWTs so attractive for stateless authentication across distributed services.

Signed does not mean secret

The most consequential misconception about JWTs is that the payload is protected. It is not. Base64 is an encoding, not encryption, so anyone who obtains the token — from a browser's local storage, from a log file, from a proxy — can read every claim it contains in seconds. The signature guarantees integrity, meaning nobody can alter the claims without detection. It guarantees nothing about confidentiality. This has real consequences: email addresses, internal user identifiers, role names and permission lists placed in a payload should all be considered public. If a claim genuinely must be hidden, you need JWE, the encrypted variant of the standard — or, far more sensibly, you keep the secret on the server and put nothing but a reference in the token.

Related tools

Continue the workflow with adjacent tools.

URL Encode
Percent-encode and decode URLs and query strings
HTML Entities
Escape and unescape HTML entities
Base64 Text
Encode text to Base64 and decode it back