JWT Decoder

A JWT Decoder is a tool that takes a JSON Web Token and shows you what is inside it — the header, the payload and the signature — in a human-readable form.

A JWT is a compact, URL-safe way to carry claims between two parties, most often used for authentication and authorization. It looks like one long string but is really three parts joined by dots: header.payload.signature. The header and payload are JSON objects that have been BaseundefinedURL-encoded — not encrypted. That encoding makes them safe to pass in an HTTP header or URL, but it also means anyone can read them once they reverse the encoding.

That is exactly what this decoder does. Paste a token and it splits on the dots, BaseundefinedURL-decodes the first two segments and pretty-prints the resulting JSON so you can see the algorithm, the token type and every claim at a glance. The third segment, the signature, is shown as-is because it is raw bytes, not readable JSON.

When you are debugging authentication, you constantly need to answer questions like "who is this token for?", "has it expired?" and "which scopes does it carry?". Reading a raw JWT by eye is impossible, and writing a throwaway script to Baseundefined-decode it every time is slow.

An online decoder gives you the answer in one paste. There is nothing to install, no dependency to add and no CLI to remember.

The key thing about this decoder is where the work happens. The token is decoded entirely in your browser using local JavaScript — it is never sent to a server, logged or stored. That matters, because a JWT often is the credential: whoever holds it can act as the user until it expires. Pasting one into a random website that phones home is a real risk. Here, you can open your browser's Network tab and confirm no request is made when you decode.

Decoding takes seconds:

1. Copy the token. Grab it from a browser cookie, a Authorization: Bearer header, localStorage or an API response.
2. Paste it in. Drop the full header.payload.signature string into the input.
3. Read the output. The header and payload appear as formatted JSON; the signature appears as its encoded segment.
4. Interpret the claims. Check exp, iat, sub, iss and aud to understand who the token is for and whether it is still valid.

If the tool cannot decode a segment, the token is malformed — often a stray space, a truncated copy, or a value that is not a JWT at all (for example an opaque session ID).

A JWT decoder earns its place in a lot of everyday workflows:

• Debugging logins. A user reports being logged out early — decode their token and check whether exp is sooner than you expect.
• Checking scopes and roles. Confirm the payload actually carries the scope, roles or permissions claim your API is gating on.
• Verifying the issuer and audience. Make sure iss and aud match the values your service is configured to accept.
• Reading the algorithm. Look at the header's alg to confirm a token is signed with the expected algorithm (for example RS256) and not none.
• Building test fixtures. Copy a real payload structure into your test suite so mocks match production.
• Writing documentation. Show teammates exactly what claims your tokens contain without sharing a live credential.

This is the single most important thing to understand about any JWT decoder: decoding a token does not prove it is genuine.

The header and payload are only BaseundefinedURL-encoded, so anyone can decode them — and anyone can craft a token with any claims they like. What stops forgery is the signature: the third segment is a cryptographic signature over the header and payload, produced with a secret (for HS256) or a private key (for RS256/ES256). Verifying means recomputing or checking that signature with the matching secret or public key and confirming it matches.

A decoder deliberately does not do that — it has no access to your keys, and it never should. So treat decoded claims as claims, not facts. Your backend must always verify the signature (and check exp, iss and aud) before trusting anything in the payload. Use the decoder to inspect, and your server-side library to trust.

• Never paste production or long-lived tokens into any online tool. Because a JWT is a bearer credential, treat it like a password. This tool decodes locally and uploads nothing, but for real secrets prefer a short-lived or test token, and revoke anything you are unsure about.
• Remember timestamps are Unix seconds, not milliseconds. If a date looks like it is in undefined or far in the future, you are probably off by a factor of undefined.
• Don't put secrets in the payload. Anyone can read it. Store only non-sensitive claims.
• Confirm the algorithm. Reject tokens whose header alg is none or does not match what your service expects — this closes a classic JWT attack.
• Pair it with related tools. Use a Baseundefined tool to decode individual segments by hand, or a Hash Generator when you are experimenting with signing inputs. When you need to trust a token, verify its signature server-side rather than eyeballing the decode.