JWT Decoder

A JSON Web Token is a compact, signed string passed between a client and a server to prove identity. It has three parts separated by dots: header.payload.signature. Each of the first two parts is a Base64URL-encoded JSON object, which is why a raw token looks like random text. A decoder splits the token on the . separator, decodes the header and payload back into readable JSON, and shows the signature segment as-is.

With the decoded view you can read who issued the token, who it belongs to, and when it expires. This is the fastest way to debug an authentication flow when a request is rejected or a session ends sooner than expected. Paste a token and the tool returns structured JSON for each segment. If you also need to inspect raw Base64 chunks, the Base64 Encode and Base64 Decode tools handle those directly, and JSON Formatter tidies the decoded payload for closer reading.

Every JWT is built from three dot-separated segments, and knowing what each one holds makes debugging much faster.

The header names the signing algorithm, for example { "alg": "HS256", "typ": "JWT" }. The payload carries the claims, the actual data the token asserts. The signature is computed over the header and payload using a secret or private key, so it cannot be read as JSON. A decoder shows the header and payload as plain JSON but leaves the signature encoded, because decoding it would not reveal anything human-readable. Remember that decoding is not verification: anyone can read a payload, but only a holder of the key can confirm the signature is genuine.

The payload contains claims, which are simple key-value pairs. Several keys are reserved by the standard and carry specific meanings.

Time claims like exp, iat, and nbf are stored as seconds since 1,970, not as formatted dates. A decoder converts these into readable dates so you can see at a glance whether a token is still valid or already expired. The iss and aud claims matter for security: your backend should confirm the token came from the expected issuer and was meant for your service, not a different one. Any other keys, such as email, role, or scope, are custom claims your application adds on top of the reserved set. Reading them side by side helps confirm that the right permissions and identity data actually reached the server during a request, which is often where an access problem turns out to hide.

A common mistake is treating a successful decode as proof that a token is trustworthy. Decoding only reverses the Base64URL encoding, which anyone can do because no secret is involved. The payload is readable by design, so you must never store passwords, API keys, or other secrets inside a JWT.

Verification is a separate step. It recomputes the signature using the signing key and checks that it matches the signature in the token. Only verification confirms that the token was issued by your server and has not been altered along the way. If even one character in the header or payload changes, the recomputed signature no longer matches and the token is rejected. A decoder, by contrast, is a read-only inspection tool: it shows you what a token claims, not whether those claims are authentic. Use it during development to confirm the payload looks right, then rely on your backend library to verify the signature and enforce the exp and aud claims before granting access. Never make an access decision in client code based on a decoded payload alone, since the client cannot trust what it has not verified.

A decoder earns its place whenever an authenticated request behaves unexpectedly. If an API returns a 401, paste the token and check the exp claim to see whether it simply expired. If a user lacks access they should have, inspect the role or scope claims to confirm the right permissions were issued.

It also helps when integrating a new identity provider. Comparing the claims you receive against the claims your code expects quickly reveals mismatched key names, a missing scope, or a wrong aud value before it reaches production. During local testing you can decode tokens pulled from logs to trace which session caused a problem and when it was issued.

Because the decoded payload is plain JSON, you can copy it into JSON Formatter for a clean, indented view of nested objects. Keep in mind that tokens often grant real access, so avoid pasting production tokens into any tool you do not trust, and clear sensitive values when you are done.