What is a JSON Web Token?
A JSON Web Token, or JWT (pronounced "jot"), is a compact and URL-safe way to represent a set of claims — pieces of information — that can be transferred between two parties and cryptographically verified. The format is defined by RFC 7519, and it has become the de facto standard for stateless authentication in modern web and mobile applications. When you sign in to an app and it issues an access token, there is a very good chance that token is a JWT.
A JWT is just three strings joined by dots — header.payload.signature — so it looks like a long opaque blob, but it is entirely readable once decoded. That is what this tool does: it splits a token into its three parts, Base64URL-decodes the header and payload, and shows you the JSON inside, along with a plain-English explanation of every standard claim it recognises. Nothing is sent anywhere; the decoding happens on your device.
The three parts of a JWT
- Header. A small JSON object that describes the token. It always includes the signing algorithm (
alg, e.g.HS256orRS256) and usually a token type (typ). It may also carry a key ID (kid) so a verifier knows which key to use. - Payload. The JSON object holding the claims — who issued the token (
iss), who it identifies (sub), who it is for (aud), when it was issued (iat), and when it expires (exp), plus any custom claims your application adds, such as roles or scopes. - Signature. A cryptographic signature over the encoded header and payload. It proves the token was issued by someone holding the signing key and that the contents have not been altered. The signature is what makes a JWT trustworthy — but only if the receiving server actually verifies it.
Decoding is not the same as verifying
This is the single most important thing to understand about JWTs. The header and payload are only Base64URL-encoded, not encrypted. That means anyone who has the token — including this tool, and including an attacker — can read every claim inside it. Decoding tells you what a token says; it does not tell you whether the token is genuine.
Verification is the separate step where a server checks the signature against the expected key and algorithm, confirms the token has not expired, and validates the issuer and audience. That step requires the signing secret or public key and must happen on your server. This site deliberately does not ask for your keys and does not verify signatures — a public decoder is the wrong place to handle secret key material. To learn how verification works in practice, see the JWT validation guide.
When should you use a JWT?
JWTs shine when you need a stateless, signed assertion that can be checked without a database lookup — service-to-service authentication, short-lived API access tokens, and OpenID Connect identity tokens are classic examples. Because the receiver can verify a JWT using only a public key, they scale well across distributed systems and microservices.
They are not a universal replacement for sessions, though. JWTs are difficult to revoke before they expire, so for long-lived logins, instant logout, or frequently changing permissions, a traditional server-side session — or a short JWT paired with a refresh token — is often the better choice. The best practices guide walks through how to make that decision, and JWT vs OAuth explains how tokens fit into the wider authorization picture.
Is it safe to decode my token here?
Yes. Every part of the decoding process runs locally in your browser. When you paste a token there is no upload, no network request, and no logging — we have no way to see the tokens you inspect. That said, because a JWT can contain real session data, you should always be careful where you paste one. With this tool you do not have to take that on faith: open your browser's developer tools, watch the network tab, and you will see that pasting a token triggers no request at all. For more detail, see the FAQ and our privacy policy.