What is inside a JSON Web Token?
A JSON Web Token (JWT) is a compact string made of three parts separated by dots: a header, a payload, and a signature. The header describes the token, such as the signing algorithm. The payload carries the claims, which are pieces of information like a user ID, an issuer, or an expiry time. The signature is produced with a secret or private key.
The header and payload are just JSON that has been encoded as Base64URL, a URL-safe variant of Base64. Encoding is not encryption, so anyone who holds the token can read those two parts. The signature is what lets a server detect tampering, but it can only be checked with the right key.
Why decode a JWT
Decoding is a debugging step. When an API returns an authorization error, you can inspect the token to see which user or scope it names, which algorithm it claims to use, or whether the claims look different from what you expected. Registered claims such as sub (subject), iss (issuer), exp (expiry), and iat (issued at) are the usual things to look for.
It also helps when learning how a login system works, or checking what personal data a token exposes. If you want to create a token for testing rather than inspect one, the JWT Encoder signs one locally with a payload and secret you provide.
How to decode a JWT with this tool
- Paste the token into the "Paste a JWT" box. A sample token is already there, so replace it with yours.
- Read the Header and Payload panels that appear below, shown as formatted JSON.
- If something is wrong, an error message appears instead. It either says a JWT has three dot-separated parts, or that the token could not be decoded as Base64URL JSON.
Decoding runs in your browser as you type, and the tool does not contact a server. The signature, the third part, is not shown or checked.
Decoding is not verification, and tokens are sensitive
This tool only reads the header and payload. It does not verify the signature, so a successful decode says nothing about whether the token is genuine, unaltered, or accepted by any system. It also does not check whether the token has expired: exp and similar claims are shown as raw numbers, and you must interpret them yourself. Never trust a decoded token as proof of identity. Verification must be done by the server using the proper key.
Treat real tokens like passwords. A valid access token can let someone act as the user until it expires, so avoid pasting live production tokens into places you do not control, and do not share them in chat or tickets. Here the processing is local, but good habits are worth keeping: prefer test tokens when you can, and rotate or revoke any token you believe has been exposed.