JWTs (JSON Web Tokens) power authentication in most modern web and mobile apps, but the actual structure of a JWT — and what's safe to do with one — confuses a lot of developers debugging an auth issue for the first time. Part of our Complete Developer Tools Guide.
The 3 Parts of a JWT
A JWT has the structure header.payload.signature:
- Header — algorithm and token type (e.g. HS256, RS256).
- Payload — claims and data: user ID, expiry, roles, etc.
- Signature — cryptographic proof the token wasn't tampered with, generated using a secret key the server holds.
Decoding vs Verifying
"Decoding" a JWT (reading the header/payload) requires no secret key — anyone can do it, since the payload is only Base64-encoded, not encrypted. "Verifying" a JWT (confirming the signature is valid and the token is genuine, not forged) requires the secret or public key. WorkUtilities JWT Decoder does both: it decodes instantly and can verify signatures when you provide your key.
Signature Verification (Client-Side)
The JWT Decoder supports signature verification for common algorithms — HMAC (HS256, HS384, HS512), RSA (RS256, RS384, RS512, PS256), and ECDSA (ES256, ES384, ES512). The algorithm is auto-detected from the token header.
- HMAC (HS*) — paste your shared secret. Toggle "base64 encoded" if your secret is stored as Base64.
- RSA / ECDSA (RS*, ES*, PS*) — paste the public key in PEM format (
-----BEGIN PUBLIC KEY-----).
Verification runs entirely in your browser using the Web Crypto API — your secret never leaves the page. You'll see ✅ Signature Verified or ❌ Invalid Signature. If no key is provided, the tool still decodes the token and shows an informational message to add a key.
Claims Explainer
Standard JWT claims use short keys. The decoder shows both the key and its expanded name, similar to jwt.io:
iss— Issuer (who created the token)sub— Subject (who the token is about)aud— Audience (intended recipient)exp— Expiration Time (when the token expires)nbf— Not Before (token not valid before this time)iat— Issued At (when the token was created)jti— JWT ID (unique token identifier)
Timestamp claims (exp, iat, nbf) show both the Unix timestamp and a human-readable date. When exp is present, the payload panel shows a green valid badge or red expired badge with time remaining.
Never Put Secret Data in the Payload
Since the payload is just Base64-encoded (readable by anyone holding the token), JWTs should only contain non-sensitive claims (user ID, role, expiry) — never passwords, SSNs, or anything that needs to stay confidential.
Common Debugging Use Case
Check token expiry (exp claim) when debugging "why am I getting logged out" or "why is my API call returning 401" issues. The decoded payload reveals this instantly. Use the JWT Decoder — the payload itself is JSON; see also How to format JSON online free.
Frequently Asked Questions
Can I decode a JWT without the secret key?
Yes — decoding only requires reading the Base64-encoded header and payload, which requires no key. Verifying the signature (confirming the token is genuine) does require the secret/private key.
Is JWT payload data encrypted?
No, it's only Base64-encoded, which is trivially reversible — never put sensitive secret data in a JWT payload, since anyone holding the token can read its contents.
Why does my JWT decoder show valid data even for an expired or invalid token?
Decoding always reads the token's contents — but WorkUtilities JWT Decoder also checks the exp claim and shows expired/valid badges. Signature verification requires your secret or public key; without it, the tool shows decoded claims but cannot confirm the token is genuine.
What's the difference between a JWT and a session cookie?
A JWT is self-contained (the server can verify it without a database lookup, since the data and signature travel with the token). A traditional session cookie just holds an ID that the server looks up in a session store.