JWT Decoder

What a JWT decoder does

A JSON Web Token (JWT) is a compact, URL-safe string that web apps and APIs use to carry signed information — most often "who is this user and what are they allowed to do." It looks like three chunks of gibberish separated by dots, but it is not encrypted: each part is just Base64URL-encoded JSON. This decoder splits the token, decodes the header and payload back into readable JSON, and lays out the standard claims so you can see exactly what a token contains. It is the fastest way to debug authentication while building or testing an API.

How to decode a token

Paste your JWT into the box. Decoding happens instantly and entirely in your browser as you type — the token is never sent to our server, which matters because tokens often grant access to real accounts. You will immediately see the decoded Header, the decoded Payload, and a table of registered claims with timestamps converted to human-readable dates.

The three parts of a JWT

Header — describes how the token is signed. The alg field names the algorithm (e.g. HS256, RS256) and typ is almost always JWT. A kid (key ID) may point to which signing key was used.

Payload — the actual data ("claims"), such as the user ID, roles, and expiry. Anyone who has the token can read this, so never put passwords or secrets in a JWT payload.

Signature — a cryptographic stamp created from the header, payload, and a secret (or private key). It lets a server confirm the token has not been altered. This tool shows the signature but does not verify it — see the security note below.

The registered claims explained

The JWT standard reserves a handful of short claim names. This decoder highlights the common ones: iss (Issuer) — who created the token. sub (Subject) — who the token is about, usually a user ID. aud (Audience) — who it is intended for. exp (Expires) — a Unix timestamp after which the token is invalid; the decoder flags whether it is expired. nbf (Not before) — a time before which the token should be rejected. iat (Issued at) — when it was created. jti (JWT ID) — a unique identifier used to prevent replay.

Decoding is not the same as verifying — a security note

Reading a JWT and trusting a JWT are very different. Because the payload is only encoded (not encrypted), anyone can decode it — that is exactly what this tool does. What proves a token is genuine is the signature, and verifying it requires the secret or public key, which should only ever live on your server. For that reason this tool intentionally never asks for your secret and does not claim a token is valid; it only shows you what is inside. Always verify signatures server-side, and always check exp before trusting a token.

Common uses

Developers reach for a JWT decoder to debug login flows ("why is this user getting a 401?"), to confirm an API issues the claims they expect, to read a token's expiry while reproducing a bug, and to inspect tokens from OAuth and OpenID Connect providers. QA testers confirm role claims; support engineers read a customer's token without ever touching the signing key.

Frequently asked questions

Is my token sent anywhere? No. Everything is decoded with JavaScript in your browser; the token never leaves your device.

Can this tool tell me if a token is valid? It checks structure and expiry, but it cannot verify the signature without the secret/public key — and you should never paste those into any website. Verify signatures on your server.

Why is my payload readable — is that a bug? No. JWT payloads are encoded, not encrypted. Readable data is normal, which is why secrets must never be stored in them.

What does "EXPIRED" mean? The exp timestamp is in the past, so a correctly-implemented server will reject the token. Request a fresh one.