A JWT (JSON Web Token) shows up everywhere — login sessions, API auth, OAuth flows. But most "JWT decoders" on the web ask you to paste your token into their server. This guide shows what a JWT actually contains and how to inspect one privately.
Anatomy of a JWT
A JWT is three Base64URL-encoded segments joined by dots:
header.payload.signature
- Header — metadata: the signing algorithm (
HS256,RS256) and token type. - Payload — the claims:
sub,exp,iat, and any custom data. - Signature — verifies the token wasn't tampered with.
A worked example
A decoded header often looks like {"alg":"HS256","typ":"JWT"}. The payload might be
{"sub":"123","name":"Ada","exp":1754200000}. The signature is a hash you cannot reverse,
but you can verify it if you hold the secret.
The header algorithms explained
- HS256 — HMAC with a shared secret; both sides must keep it safe.
- RS256 — RSA with a public/private key pair; the public key can verify.
- ES256 — elliptic-curve signing; smaller signatures, growing adoption.
Standard claims reference
sub— the subject (who the token is about).exp— expiry timestamp; after this the token is invalid.iat— issued-at timestamp.nbf— not-valid-before; rejects tokens used too early.aud/iss— audience and issuer the API checks.
What you can read vs. trust
Decoding reveals the payload, but decoding is not verification. Anyone can decode a JWT; only the signature proves it is authentic. A decoded exp (expiry) claim tells you when the token stops being valid.
The security risk of pasting tokens
A live JWT often grants access to a real account. Pasting it into an unknown website hands that access to a third party. Client-side decoding keeps the token on your machine.
When you should NOT decode client-side
Never enter the secret or private key into any web tool. Verification belongs server-side. Use a decoder only to inspect public structure, never to "validate" trust.
Decode locally
The DevToolbox JWT Debugger splits your token into its three parts and shows the decoded JSON instantly. Because it runs in your browser, your token never leaves your machine — critical when that token grants access to a real account.
- Paste the token into the field.
- Read the decoded header and payload.
- Check the
expclaim to see if it has expired.
- Is a JWT encrypted?
- No — it is encoded, not encrypted. The payload is readable by anyone who has the token. Use TLS and short expiries.
- Can I verify the signature here?
- Signature verification needs the secret or key, which you should never enter on a shared site. Decode for inspection; verify server-side.
Public vs private claims
Claims fall into registered (sub, exp…), public (registered in a namespace
to avoid collisions), and private (agreed between parties). When inspecting an unknown token, the
private claims are whatever the issuer decided — decode them to understand the session, but don't assume their meaning.
Why exp alone isn't security
An expiry limits a token's window, but it does not authenticate it. A stolen token is valid until it expires. Real security comes from short expiries, rotation, and binding the token to a device or session.
Refresh token inspection
Refresh tokens are longer-lived and even more sensitive than access tokens. Decoding one client-side to check its claims is fine; storing or logging it is not. Treat it like a password.
Libraries that decode JWT
- Auth0 / jwt.io — educational decoder (but server-side; don't paste secrets).
- jsonwebtoken (Node), PyJWT (Python) — decode and verify in code.
- DevToolbox JWT Debugger — client-side, nothing uploaded.
The signature, simply explained
Think of the signature as a tamper-evident seal made with a secret or key. If anyone changes the payload, the seal no longer matches — but only someone with the key can confirm that. Decoding shows you the contents; verifying confirms the seal, and that second step needs the key you should never share.
Common alg values
You will mostly see HS256, RS256, or ES256 in the header.
Recognizing them tells you which kind of key the server uses to verify, which is useful when debugging
a "signature invalid" rejection.
Where JWTs appear
Beyond login, JWTs secure API-to-API calls, single sign-on, and mobile app sessions. Anywhere a stateless claim of identity is useful, you'll find them — which is why a fast, private way to inspect them belongs in every developer's toolkit.
Stateless auth, explained
Because the signature carries the trust, a server can validate a JWT without a database lookup. That scalability is the appeal — but it also means a compromised token can't be revoked mid-flight, which is why short expiries matter.
A minimal mental model
If you remember nothing else: a JWT is three parts — a header saying how it's signed, a payload of claims anyone can read, and a signature only the issuer can verify. Decode to inspect; never treat a decoded token as proof of anything. That single distinction prevents most JWT mistakes.