JWT explained: header, payload, signature
A JSON Web Token is three Base64URL segments joined by dots: the header says which algorithm signed it, the payload carries the claims (who, when issued, when expires), and the signature proves neither was tampered with. Stateless authentication in one string.
Two things everyone should know: the payload is readable by anyone — decoding is not hacking — so never put secrets in it. And decoding is not verifying: reading claims proves nothing about authenticity. That is why this tool does both, with HS256 signature verification when you supply the secret.
Open the free JWT Decoder — no signup, runs entirely in your browser.
How to use it
- Paste the token — all three dot-separated segments.
- Read the decoded header and payload, with iat, exp and nbf rendered as real dates.
- Optionally paste the HS256 secret to verify the signature on the spot.
Why this one
- Header, payload and signature broken out and explained.
- Numeric date claims rendered as ISO dates, with valid, expired or not-yet-valid status.
- HS256 signature verification right in the browser via WebCrypto.
- Fully client-side — tokens and secrets never touch a server.
Frequently asked questions
Is it safe to paste a JWT into an online decoder?
Only if it never leaves your machine — which is exactly how this one works: decoding happens in your browser, nothing is transmitted. Pasting production tokens into server-side decoders means handing them to a stranger.
Is decoding a JWT the same as verifying it?
No. Decoding just reads the payload — anyone can do it, and it proves nothing. Verification checks the signature against the secret or public key, proving the token was issued by the key holder and was not modified.
What are the standard JWT claims?
iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), nbf (not before) and jti (token id). Everything else is custom — and everything in the payload is visible to whoever holds the token.