JWTs are the currency of modern auth. Reading them by eye is impossible; sending them to a third-party decoder is a bad habit. The ChrysoKit JWT Decoder gives you a clean, local view of any token in seconds.
Why use it
Tokens often contain identifying claims. Decoding them on a remote site is a small leak that adds up. Ours runs entirely in the browser; the token never leaves your machine.
How to use the JWT Decoder
- Paste the JWT into the input field.
- Read the header, payload and signature in three labelled panels.
- Hover any timestamp to see the human-readable date.
- Copy any panel as JSON with one click.
Features worth knowing
Three-panel view
Header, payload and signature shown side by side.
Timestamp expansion
iat, exp and nbf are shown both as numbers and as readable dates.
Local only
The decoder runs entirely in the browser. Nothing is logged or sent anywhere.
Pro tips
- Decoding a JWT is not the same as verifying it. The signature panel shows the value but does not validate it without a key.
- Watch for the 'alg' header. 'none' is a red flag, and so is HS256 where you expected RS256.
- Tokens with extremely long lifetimes (months or years) deserve scrutiny. Short, refreshable tokens are the modern norm.
Privacy first. The JWT Decoder runs entirely in your browser. Nothing you enter is sent to a server.
Open the JWT Decoder the next time a token lands in your terminal. It is faster, safer and easier to read.
Open the tool: JWT Decoder →
Reading a token during an API integration: a practical session
Integrating against a third-party API, the authentication works in the test environment and fails in production with an unhelpful 401. Before opening a support ticket, paste the failing token into a decoder and read what it actually says... a five-minute habit that resolves a remarkable share of integration mysteries.
The session goes like this. The payload's exp claim translates to a timestamp forty minutes ago: the token was minted at deploy time and cached, and nobody refreshes it. That alone explains many production-only failures, since test runs mint fresh tokens every time. Next check, aud: the token says api.sandbox.example while production calls api.example... the client was configured with sandbox credentials in one environment variable out of five. Finally iss and the header's alg confirm the token comes from the expected issuer with the expected algorithm, which rules out the more exotic failure modes before they consume an afternoon.
None of this required secrets or verification keys, because the questions were about the token's claims, not its authenticity... exactly the decoder's jurisdiction. The companion habit for the other direction: when your own API rejects tokens, log the claims (never the full token) at the rejection point. Most "authentication is broken" tickets are an expired exp or mismatched aud wearing a trench coat.