How to Decode and Verify a JWT

Decode a JSON Web Token to read its header and claims, check expiry, and understand signature verification — safely, without uploading the token.

Updated 5 min read By CodingEagles
Free tool JWT Decoder Decode a JWT header and payload, check expiry, verify HS256. Open tool

A JSON Web Token (JWT) is the little xxxxx.yyyyy.zzzzz string that authenticates most modern APIs. When something’s wrong with auth, the first move is to look inside the token — read its claims, check the expiry, confirm the signature.

This guide explains the three parts of a JWT and how to decode and verify one safely.

TL;DR — Paste a token into the JWT decoder to read its header and payload and check exp. It runs in your browser, so your token — a credential — never leaves your device.

The three parts

A JWT has three Base64URL-encoded sections separated by dots:

  1. Header — the algorithm (alg, e.g. HS256 or RS256) and token type.
  2. Payload — the claims: who the token is for and what it allows.
  3. Signature — a cryptographic signature over the first two parts.

The header and payload are only encoded, not encrypted. Decoding them is trivial and reveals everything inside, which is why you must never put secrets in a JWT payload.

Reading the claims

The payload holds standard registered claims:

  • iss — issuer (who created the token).
  • sub — subject (usually the user ID).
  • aud — audience (who the token is for).
  • exp — expiry, a Unix timestamp. After this, the token is invalid.
  • iat — issued-at time.
  • nbf — not-before time; the token isn’t valid until then.

A decoder converts exp, iat and nbf to human time and flags whether the token is active, expired, or not yet valid — usually the answer to “why is my auth failing?”.

Decoding vs. verifying

Decoding reads the claims. Verifying proves they can be trusted. Without verification, anyone can craft a token with any claims they like — decoding alone tells you nothing about authenticity.

  • HS256 (HMAC) tokens are verified with a shared secret. Given the secret, the decoder recomputes the signature and confirms it matches.
  • RS256 / ES256 tokens are signed with a private key and verified with the matching public key. The decoder can read them, but verification needs that public key.

Your application must always verify the signature server-side before trusting a token’s claims.

Keep the token private

Because a JWT is a credential, where you decode it matters. Many online decoders transmit whatever you paste. The JWT decoder here decodes and verifies entirely in your browser — nothing is uploaded, so it’s safe for real tokens.

Frequently asked questions

Is a JWT encrypted?
Usually not. A standard JWT is signed, not encrypted — the header and payload are only Base64URL-encoded, so anyone can read them. The signature proves the token wasn't altered; it does not hide the contents.
What is the difference between decoding and verifying?
Decoding just Base64URL-decodes the header and payload so you can read the claims. Verifying recomputes the signature with a key to prove the token is authentic and untampered. Never trust a token's claims without verifying.
Why is it risky to paste a JWT into an online decoder?
A JWT is a live credential. If a decoder sends it to a server, that server could capture and reuse it. This decoder runs entirely in your browser, so your token never leaves your device.

Ready to try it?

Decode a JWT header and payload, check expiry, verify HS256. Free, in-browser, and 100% private — your data never leaves your device.

Open the JWT Decoder

Related guides

How to Encode and Decode Base64 What Base64 actually does, when to reach for the URL-safe variant, and how to encode files as well as text — without uploading anything.