How to Decode a JWT (and Why Decoding Is Not Verifying)

You are debugging an auth flow and someone hands you a long string of gibberish: eyJhbGciOi.... That is a JSON Web Token, or JWT, and inside it is structured data you can read in seconds once you know how. This guide explains what a JWT is made of, how to decode it to inspect its claims, and the one security point that trips up developers constantly: decoding a token is not the same as verifying it. You can follow along with the free JWT Decoder.

What a JWT is made of

A JWT is a compact way to carry signed information between two parties, most often to prove who a user is after they log in. Look closely and you will see it is split into three parts separated by dots:

header.payload.signature

Each of the first two parts is a JSON object that has been Base64url encoded, which is why it looks like random characters rather than readable text. The three pieces are:

• Header. Small JSON describing the token, mainly the signing algorithm (like HS256 or RS256) and the token type.
• Payload. The interesting part. This holds the claims: who the user is, when the token was issued, when it expires, and any custom data the issuer added.
• Signature. A cryptographic stamp created from the header, the payload, and a secret key. It is what lets a server confirm the token was not tampered with.

The dots are literal separators, so a JWT is always three Base64url chunks joined by periods.

How to decode and read the claims

Decoding simply reverses the Base64url encoding on the header and payload so you can read the JSON inside. The free JWT Decoder does this instantly and, importantly, runs entirely in your browser, so the token you paste is never sent anywhere.

1. Copy the full token, all three parts including the dots.
2. Paste it into the JWT Decoder.
3. Read the decoded header and payload as formatted JSON.

In the payload you will often see standard claims: sub for the subject (usually a user id), iat for issued-at time, exp for the expiry, and iss for the issuer. The time values are typically Unix timestamps. Reading them is the fastest way to answer questions like “is this token expired?” or “which user is this for?” while debugging.

Decoding is not verifying

Here is the point worth tattooing on your memory. Anyone who has the token can decode the header and payload, with no key and no password. The encoding is reversible by design, exactly like Base64. Decoding tells you what the token claims, but it tells you nothing about whether those claims are trustworthy.

Verifying is a separate, cryptographic step. A server recomputes the signature using the secret or public key and checks that it matches the signature in the token. Only a valid signature proves the token was issued by who it says and has not been altered. A decoder cannot do this for you, because it does not have the key. So never decide “this user is authenticated” based on a decode alone, that check has to happen on the server with the proper key.

Never put secrets in the payload

Because the payload is trivially readable by anyone holding the token, it is the wrong place for anything sensitive. Do not put passwords, API keys, or private personal data in a JWT payload, since it is effectively public to anyone who intercepts or is given the token. The signature stops tampering, not reading. Treat the payload as visible by default and keep secrets server-side.

Related tools for inspecting tokens

A JWT decode often leads to a few neighboring tasks. If you want to understand the Base64url layer itself, the Base64 Encode and Decode tool lets you experiment with the same encoding the token uses. Once you have a decoded payload, the JSON Formatter will indent and tidy it so a deeply nested claim set is easy to scan. And if you are reasoning about how the signature is built, the Hash Generator is a good way to see how one-way hashing behaves, since signing relies on related cryptographic primitives.

The short version

A JWT is three Base64url-encoded parts, header, payload, and signature, joined by dots. Decoding reverses the encoding so you can read the claims, which is perfect for debugging. Just remember that decoding is not verifying: the payload is readable by anyone, so never store secrets in it, and always verify the signature on the server before trusting a token. When you need to inspect one quickly and privately, the free JWT Decoder reads it right in your browser.