JWT Decoder
Fixpio’s JWT decoder shows the header and claims inside a JSON Web Token — decoded in your browser, with the signature clearly labelled as not verified.
Decode a JSON Web Token
Paste a token to read its header and claims.
Read tokens without trusting them
Clarity about what a token says — and what that does not prove.
A JWT is not encrypted
The payload is merely base64url-encoded — anyone who has the token can read everything in it. Never put secrets, passwords or personal data in a JWT payload.
Decoding is not verifying
The signature proves a token was issued by someone holding the key and was not altered. Only your server, with the key, can check it — a decoder cannot and should not claim to.
Why exp matters
An expired token should be rejected by any correct API. Seeing the exact expiry date — not just a raw timestamp — makes debugging auth failures much faster.
About this JWT decoder
This JWT decoder shows you what is inside a JSON Web Token. A JWT has three base64url-encoded segments joined by dots: a header describing the token type and signing algorithm, a payload carrying the claims (the statements the token makes — who it is about, who issued it, when it expires), and a signature. Paste a token and the tool decodes the first two segments into readable JSON, lists each claim with a plain-English meaning, and converts the standard time claims — exp (expiry), iat (issued at), nbf (not valid before) — into real dates with an expiry status.
The most important thing this page can teach is what decoding does NOT do. Decoding is just translation: the payload of any JWT can be read by anyone who holds it, exactly as this page demonstrates, and reading it says nothing about whether the token is genuine. Trust comes only from verifying the signature against the issuer’s key, which must happen on a server with access to that key. For that reason the decoded signature segment here is displayed for inspection and explicitly labelled unverified — any tool that shows a “valid” tick without the key is misleading you.
Everything happens locally in your browser. That matters more for this tool than most: a live JWT is a working credential, and pasting one into a server-side decoder hands that credential to whoever runs the server. Here, the token never leaves your device, and nothing is stored after you close the tab.
Frequently asked questions
Decoding vs verifying, expiry, safety and claim names.
What does this JWT decoder actually do?
It base64url-decodes the header and payload segments of a JSON Web Token and shows them as formatted JSON, lists the claims with plain-English meanings, and converts the time claims into readable dates. It works on any standard JWT, including ones with a “Bearer ” prefix pasted in.
Can this tool verify that a token is genuine?
No — and it says so on purpose. Verification requires the issuer’s secret key or public key and must be done by the system that issued or consumes the token. This tool decodes; it never marks a token “valid”, and you should distrust any decoder that does.
Is it safe to paste a real token here?
The decoding happens entirely in your browser — the token is never uploaded, logged or stored. That said, treat live tokens as credentials generally: avoid pasting them into server-side tools, screenshots or tickets.
Why does the payload show a name like “sub” or “jti”?
JWT claims use short registered names: sub is the subject (usually a user ID), iss the issuer, aud the intended audience, exp the expiry, iat the issue time, nbf the not-before time and jti a unique token ID. The claims table translates each one it finds.
My token shows as expired. What now?
The exp claim is in the past, so correctly behaving APIs will reject it. In your own app, sign in again to get a fresh token; if tokens expire immediately, check for clock skew between the issuer and your device, and confirm you pasted the whole token.
Why are there three parts separated by dots?
The format is header.payload.signature. The first two are JSON, encoded so they survive URLs and HTTP headers; the third is the signature over the first two. Removing or altering any character of the first two parts invalidates the signature — which is exactly what verification checks.