JWT Decoder

What a JWT Decoder actually does

A JSON Web Token (JWT) looks like a long, opaque string of random characters, but it is not encrypted and it is not a secret cipher. It is a compact, URL-safe container that carries structured data between two parties. Paste a token into the decoder above and it splits that string apart and shows you the real JSON inside — the metadata, the claims, who the token is for, and when it expires. Everything happens right in your browser. The token is never uploaded, logged, or sent anywhere, which matters a great deal when the thing you are inspecting is a live session credential.

Three parts, two dots

Every well-formed JWT is three Base64url-encoded strings joined by dots: header.payload.signature. That single dot character is how parsers know where one section ends and the next begins, and it is why a token with the wrong number of dots is rejected before anything else is even read.

The header is a tiny JSON object describing the token itself. It almost always contains typ (the type, usually JWT) and alg — the signing algorithm, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). The header tells a verifier exactly how the signature was produced.

The payload is the part most people care about. It is another JSON object holding the claims — statements about the user and the token. The spec sorts claims into registered (standard, reserved names), public, and private (custom names you invent for your own app). Decoding the payload is what reveals who is logged in, what role they hold, and when their session lapses.

The signature is the cryptographic seal. It is computed over the encoded header and payload using the algorithm from the header plus a secret or private key. Because it covers both other sections, any change to the header or payload — even a single character — invalidates it.

The claims you will see most

The registered claims are short, three-letter names defined by RFC 7519 so different systems can interoperate. A handful show up almost everywhere:

• iss — issuer: who minted the token (your auth server or identity provider).
• sub — subject: the principal the token is about, typically a stable user ID.
• aud — audience: the recipient the token is intended for. An API should reject tokens whose audience is not itself.
• exp — expiration time: a Unix timestamp after which the token must not be accepted.
• iat — issued at: the Unix timestamp when the token was created.

You may also meet nbf (not before) and jti (a unique token ID). Timestamps are seconds since 1970 in UTC, which is why a decoder that renders them as human-readable dates saves you the mental arithmetic of checking whether a token has already expired.

Decoding is not verifying — this is the part that bites people

This distinction is the single most important thing to understand about JWTs. Decoding means reading the contents: it requires no key and anyone holding the token can do it, because Base64url is an encoding, not encryption. Verifying means proving the token is authentic and untampered — recomputing the signature with the correct secret or public key and confirming it matches.

This tool decodes. It shows you what the token says, not whether the token is trustworthy. A token could be forged, expired, or replayed and still decode into perfectly clean-looking JSON. Never make an authorization decision based on decoded claims alone. In production you verify the signature server-side, check exp, and confirm iss and aud match what you expect — using a vetted library, never hand-rolled string comparison.

A payload is not a vault

Because the payload is only Base64url-encoded, it is readable by anyone who intercepts the token. Treat everything in it as public. Do not place passwords, full credit card numbers, secret keys, or any sensitive personal data in JWT claims — if you can decode it here in one click, so can anyone else who gets a copy. The signature protects against modification, never against reading. If you genuinely need to hide payload contents, that is a job for JWE (encrypted tokens), a different specification entirely.

Privacy and related tools

Inspecting a token is a sensitive act, so this decoder runs entirely client-side — the parsing is plain JavaScript in your tab and nothing leaves your machine. Pasting a session token into a server-backed tool means handing a live credential to a third party, which is exactly what you should avoid. For the encoding underneath it all, see our Base64 tool, and explore the rest of our developer tools for more on-device utilities.

Frequently asked questions