JWT Decoder

A JSON Web Token is three Base64url-encoded strings joined by dots: header, payload and signature. The header names the signing algorithm — typically HS256 or RS256 — and the token type. The payload holds the claims: the statements the issuer is making about the subject. The signature is a cryptographic check over the first two parts.

The important thing, and the part that surprises people, is that the first two parts are only encoded, not encrypted. Base64url is a transport format, not a secret. Anyone holding a token can read its payload with no key at all — which is exactly what this page does, and why you must never put a password, a private key or anything else sensitive into a JWT payload.

Decoding here happens in your browser: the token is split on the dots, each part is padded back to a multiple of four characters, decoded with the browser's own Base64 support, and parsed as JSON. No request is made. You can load this page, disconnect from the network, and decode a token with your Wi-Fi off — which is the simplest proof that the token never went anywhere.

The canonical sample token used throughout the JWT documentation is three short strings joined by two dots. It is worth reading once slowly, because every token you meet afterwards has the same shape. Decoded, its header and payload look like this:

That iat value is a Unix timestamp: 1516239022 seconds after the epoch, which is 18 January 2018 at 01:30:22 UTC. Timestamps in JWTs are always seconds, never milliseconds — a frequent source of tokens that appear to expire fifty thousand years in the future. The signature decodes to exactly 32 bytes because HMAC-SHA256 produces a 256-bit output.

A real production token is longer but no more mysterious. Alongside the registered claims below you will usually find whatever your identity provider chose to add — scope or permissions, a tenant or organisation id, an email, sometimes a role. Those custom names are not standardised, so two providers will spell the same idea differently.

Most of what you will read, though, comes from a small set of registered claim names. They are three letters each, and they are worth knowing by sight:

It depends entirely on where the decoding happens, and most decoders do not tell you.

A JWT is a bearer credential. That is the whole design: whoever holds the token can act as its subject, with its scopes, until it expires — no password, no second factor. A production access token pasted into a page that sends it to a server has been handed to a third party you have not audited, and it stays valid for as long as its exp says. If that token belonged to a customer or an admin account, you have created a real incident, and one that is genuinely difficult to notice afterwards.

Plenty of popular decoders are server-side. The token goes into a form, the form posts it, and a backend returns the decoded JSON. It may be logged in an access log, held in an error tracker, or cached. None of that is necessarily malicious — it is simply how the page was built — but it is indistinguishable from the outside.

This page decodes in the browser, and you do not have to take our word for it. Open your developer tools, switch to the Network tab, paste a token and watch: nothing is sent. Or load the page, turn off your Wi-Fi, and decode anyway. Either check takes ten seconds and settles the question for any tool, including this one.

Two habits are worth keeping regardless. Prefer an expired or test token when you only need to see the shape of a payload. And if you have already pasted a live production token into a tool you are unsure about, rotate it — revoking one token is cheap, and finding out later that it was retained is not.

It does not verify the signature. Verification needs the shared secret or the issuer's public key, and neither belongs in a web page — a public tool that asks you for your signing secret is asking for the one thing that lets it mint tokens of its own. Signature verification is a server-side job, done by your auth library, against a key you control. This tool reads the token; it does not tell you whether to trust it.

That distinction matters more than it sounds. A decoded payload showing role: admin proves nothing on its own — anyone can craft that payload and Base64url-encode it. Only a verified signature makes a claim trustworthy.

It also cannot read an encrypted token. JWE tokens have five parts rather than three and their payload is genuinely ciphertext, so there is nothing to display without the decryption key. Nested tokens — a JWT carried inside another JWT — decode one layer at a time; paste the inner token back in to go deeper. Malformed input gets a plain error rather than a partial guess, because a half-decoded credential is worse than none.