A JSON Web Token, usually called a JWT, is a long string of characters separated by two dots into three parts. You meet them in login flows, API authentication, and password-reset links, and at first glance they look like random text. They are not random. The first two parts are ordinary JSON data, encoded in a compact text form, and anyone who holds the token can decode and read them. That readability is by design — but it is also the source of the most common misunderstanding about JWTs: reading a token is not the same as trusting it.

The JWT Decoder decodes a token in your browser. You paste the token, and it shows you the header and the payload as readable JSON. It does not check whether the token is genuine, and that distinction is the most important idea in this guide.

How the tool works

A JWT has three parts, separated by dots: header, payload, and signature. The header and payload are encoded with base64url, a variant of base64 that uses URL-safe characters and omits padding. Decoding them is simply reversing that encoding to recover the original JSON text. The header typically names the signing algorithm and the token type, for example {"alg": "HS256", "typ": "JWT"}. The payload, also called the claims set, carries the actual information: who the token is for, who issued it, when it was issued, when it expires, and any application-specific claims such as roles or permissions.

The signature is different. It is not encoded JSON; it is a cryptographic value computed over the header and payload using a secret key (for symmetric algorithms) or a private key (for asymmetric algorithms). The decoder can show you the signature part, but it cannot reverse it into data, because there is no data in it to recover — it is a check value, not a container. Verifying a signature means recomputing it with the right key and comparing the result, which is a separate operation from decoding, and it requires a key that the decoder does not have unless you provide it.

Decoding runs in your browser, which matters a great deal for tokens. A JWT may contain a user identifier, an email address, or role information, and pasting it into a remote website would hand that information to a third party. A browser-based decoder keeps the token on your device. Even so, treat every token as sensitive: decode only tokens you are entitled to inspect, such as your own test tokens, and never paste a production token into a chat, a screenshot, or a public tool.

A worked example

Take this well-known example token, which appears in many JWT tutorials as a sample. Its payload, once decoded, reads:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Each claim has a meaning. sub is the subject: the identifier of the user or entity the token refers to, here the string "1234567890". name is an application claim carrying a display name. iat stands for "issued at", and its value is a Unix timestamp — the number of seconds since 1 January 1970. The value 1516239022 corresponds to 18 January 2018. You can verify that conversion with any timestamp converter, and the habit of converting timestamps rather than guessing at them is worth forming: a raw ten-digit number tells you nothing at a glance, but a date tells you immediately whether a token is fresh or years old.

Notice what this sample payload does not contain: there is no exp claim, which would state when the token expires. A token without an expiry never expires on its own, which is a design choice with real consequences — a leaked token without an expiry remains usable indefinitely unless the issuing system revokes it some other way. When you decode a real token, the expiry claim is one of the first things to look for, along with the issuer (iss) and audience (aud) claims, which say who created the token and who it is intended for. A token issued for one service should not be accepted by another, and the audience claim is how that boundary is expressed.

To read a token yourself, split it at the dots and decode the first two segments as base64url. If a segment will not decode, check that you copied the whole token: a missing character at either end, or a line break introduced by copying from a wrapped display, will break the decoding. If the header decodes but the payload does not, you may have the segments in the wrong order, or the token may be truncated.

Common mistakes

The most dangerous mistake is treating a decoded token as a verified token. Decoding only reverses an encoding; it performs no cryptographic check at all. Anyone can create a token with any payload — including a payload claiming to be an administrator — and it will decode perfectly, because decoding does not ask whether the signature is valid. Only verification, with the correct key, can answer that question. If you are debugging an authentication problem, decoding tells you what the token claims; verification tells you whether to believe it. Never accept a decoded payload as proof of identity.

The second mistake is putting sensitive data in a payload. Because the header and payload are only encoded, not encrypted, anyone who obtains the token can read them. Passwords, secret answers, and personal data do not belong in a JWT payload. If a value must stay private, it should not be in the token at all, or the token should be encrypted rather than merely signed — a different token format with its own handling.

The third mistake is ignoring the expiry and audience claims. A token that expired yesterday should be rejected even if its signature is valid, and a token issued for one application should not be accepted by another. When a login mysteriously fails, decode the token and check those two claims before assuming the signature is at fault: an expired token and a wrong-audience token are both common causes, and both are visible in the decoded payload.

The fourth mistake is sharing tokens carelessly while debugging. Developers often paste tokens into issue trackers, chat messages, and screenshots to ask for help. A token is a credential: anyone holding it can often impersonate the user it belongs to until it expires. When you need help, decode the token locally, share the decoded claims with sensitive values redacted, and keep the token itself private. If a token has been shared publicly, treat it as compromised and revoke or rotate it.

Honest limitations

A decoder decodes; it does not verify a signature without a key, and it does not tell you whether the token is trustworthy, current, or intended for you. It cannot check revocation — whether the issuing system has cancelled the token — because revocation state lives on the server, not in the token. It also cannot decode an encrypted token's contents without the decryption key, and it cannot repair a malformed or truncated token. Some tokens use algorithms or claim formats the decoder may display without interpreting, such as custom claims whose meaning is defined by the issuing application, not by any standard. In those cases the decoder shows you the values, but only the application's documentation can tell you what they mean.

Closing

Decode to understand, verify to trust, and never confuse the two. Check the header algorithm, read the subject, issuer, audience, and expiry claims, and remember that everything in the payload is readable by anyone who holds the token. To check a token's signature and security properties, use the JWT Signature Verifier and the JWT Security Analyzer. For the encoding underneath it all, see Why Your Base64 String Fails to Decode (and the Fix).