No. A standard JWT is only signed, not encrypted. The payload is Base64Url encoded, which means anyone who holds the token can read the claims inside it. Never store secrets in a JWT payload.

Should I paste a real token into an online decoder?

Only into a decoder that runs entirely in your browser and does not transmit the token. Treat any live token like a password, because whoever has it can act as the user until it expires.

What does the signature prove?

The signature proves the token was issued by someone holding the signing key and has not been altered. Decoding shows the contents; verifying the signature confirms authenticity.

Last reviewed: 2026 · Updated for 2026

JWT Decoder Guide: JSON Web Tokens Explained Safely (2026)

JSON Web Tokens are everywhere in modern authentication, yet the format looks like an intimidating wall of random characters. It is not random at all — it is three encoded parts joined by dots. This guide explains each part, the claims you will see inside, and how to inspect a token safely with a free online JWT decoder.

The three parts of a JWT

A JWT is written as header.payload.signature. Each dot separates a Base64Url-encoded segment.

Header — declares the token type and the signing algorithm, for example HS256 or RS256.
Payload — the claims: the data the token carries, such as the user ID, roles and expiry.
Signature — a cryptographic seal over the header and payload that proves the token has not been tampered with.

Decoding just Base64Url-decodes the first two parts into readable JSON. That is why a JWT is not a secret container — the payload is visible to anyone holding the token.

Common claims you will see

sub — the subject, usually the user ID the token represents.
iat — issued-at time, a Unix timestamp of when the token was created.
exp — expiry time; after this the token should be rejected.
iss and aud — who issued the token and who it is intended for.

Those timestamps are Unix epoch seconds. If you need to turn one into a human date, our Epoch Converter does it instantly.

How to decode a token, step by step

Open the JWT Decoder and paste the full token.
Read the decoded header to confirm the algorithm.
Inspect the payload claims — check exp to see whether the token is still valid.
Confirm the tool runs entirely client-side so your token never leaves the browser.

The safety rule that matters most

A live token is a bearer credential: whoever holds it can act as that user until it expires. So treat it like a password. Never paste a production token into a decoder that sends it to a server, and never post one in a bug report, chat or screenshot. The decoder here runs in your browser, so the token stays on your machine — but the habit is what protects you. When you are done debugging, and if the token could have been exposed, rotate it.

Decoding vs verifying

Decoding and verifying are different jobs. Decoding shows you what a token says. Verifying uses the signing key to confirm the token is genuine and unchanged — that is what your server must do on every request before trusting a single claim. A decoder is a debugging aid; it deliberately does not check the signature, because it does not have your secret. If you are also inspecting the raw encoded segments, our Base64 Encoder shows how the payload is packed.

Frequently asked questions

Is the decoder free? Yes — no account, and the token is decoded locally in your browser.

Why can I read the payload without a key? Because a JWT is signed, not encrypted. The signature protects integrity, not confidentiality.

What if the token is expired? The claims still decode, but a correct server will reject it. Request a fresh token from your auth flow.

Related tools & guides

JWT Decoder →Base64 Encoder →Epoch Converter →Hash Generator →Hash Generator Guide →