A JSON Web Token looks like a solid block of noise, but it is really three readable pieces glued together with dots — and the middle piece, the payload, is plain JSON that anyone holding the token can read. This JWT decoder tool does exactly that reading for you: paste a token and it splits the three parts, base64url-decodes the header and payload, pretty-prints both as JSON, and converts the standard time claims (exp, iat, nbf) from Unix numbers into human dates so you can see at a glance when a token was issued and when it expires. The signature part is shown as-is for completeness. One fact is printed on the tool itself because it matters: this is a decoder, not a verifier — it does not check the signature, and a readable payload is never proof that a token is genuine. Debugging, though, is exactly what decoding is for: checking which user a token claims, why a session expired, or what an API actually sent you. The sample loaded above is the famous jwt.io demonstration token, and everything runs in your browser, so real tokens you paste never leave your machine.
Anatomy of the token above
The preloaded example is the best-known JWT in the world, the demonstration token from jwt.io. Its header decodes to {"alg": "HS256", "typ": "JWT"}: the signing algorithm is HMAC-SHA256 and the type is JWT. Its payload decodes to {"sub": "1234567890", "name": "John Doe", "iat": 1516239022} — subject 1234567890, a name claim, and an issued-at time that the tool converts to 2018-01-18T01:30:22Z. The third part is the signature, a base64url string computed over the first two parts with a secret key. Notice what is not there: no exp claim, so this token never expires by its own terms. Decoding any token follows the same path — split on the dots, base64url-decode (the URL-safe alphabet swaps in – and _ and drops padding), parse the JSON. If a token fails here, it is malformed or not a JWT at all; if it decodes, you are looking at claims, not facts — the distinction the next section is about.
Decoding is not verifying — and why that is fine
Verification means recomputing the signature with the issuer’s key and checking it matches, plus enforcing the claims (expiry, audience, issuer). Only the system that holds the key can do that, which is why real verification belongs on your server, never in a browser tool — a web page that “verified” a token with a key you pasted would be a strange place to put a production secret. What decoding gives you is visibility, and visibility is what most token work actually needs: support tickets (“the app says session expired” — check the exp), integration bugs (wrong audience claim, clock skew between iat and the server), and inspecting what a third-party API issued you. The unsafe move is the opposite one: trusting a payload because it decoded nicely, for example letting a client-side role claim grant access. Decode freely for debugging; verify on the server for security. The tool states this on its face so the habit sticks.
Reading the standard claims
A few payload keys are standardised (RFC 7519) and worth recognising: iss the issuer, sub the subject (usually the user ID), aud the intended audience, exp the expiry time, nbf “not valid before”, iat “issued at”, and jti a unique token ID. The three time claims are Unix seconds, which is why the tool converts them to ISO dates — 1516239022 means nothing to a human at a glance and everything once it reads 2018-01-18. If a token seems to expire early or late, compare exp against iat: the difference is the intended lifetime, and a mismatch with what you configured usually points at the issuing library’s defaults rather than at this decoder. Everything else in the payload is application-specific claims, which the JSON view shows verbatim.
Frequently asked questions
Can this tool verify a token’s signature?
No — deliberately. Verification needs the issuer’s secret or public key and belongs on a server. This tool decodes and displays; the signature is shown but never checked, and the tool says so.
Is it safe to paste a real access token?
The decoding happens entirely in your browser tab — nothing is sent or stored. Still, tokens are credentials: the good habit is to treat them like passwords, use the tool for debugging, and close the tab afterwards.
Why does my token fail to decode?
Usually one of three reasons: it is not a JWT (opaque session tokens decode to nothing meaningful), it was truncated in copying (a missing character corrupts the JSON), or a part is not valid base64url/JSON. The error message tells you which stage failed.
What does alg “none” mean in a header?
An unsigned token. Legitimate in a few narrow contexts, dangerous if an API accepts it where a signed token was expected — that acceptance bug is a classic JWT vulnerability, and spotting “none” here is a good reason to check the server side.
Related tools
Versión en español: Decodificador JWT — Lee Cabeceras y Payloads JWT de Forma Segura. You may also like: Base32 Encoder and Decoder — RFC 4648 Base32, Done in Your Browser · Cron Expression Descriptor — What Any Crontab Line Means in Plain English.
Embed this tool on your website — free
Copy the code below to add this working tool to your own page. A small credit link stays with it — that’s all we ask.
Pingback: Decodificador JWT — Decodificar Cabecera y Payload JWT Gratis Online