How to use JWT Decoder
- 1
Open the JWT Decoder
Go to tools.slaytic.com and open the JWT Decoder. No sign-up or account required.
- 2
Paste your token
Add the full token, including all three dot-separated parts.
- 3
Read the header and payload
Both are shown as formatted JSON, so you can check claims, expiry and the signing algorithm.
How this works in your browser
A JWT is three Base64URL-encoded segments joined by dots: a header describing the signing algorithm, a payload of claims, and a signature over the first two. Decoding is simply Base64URL decoding of the first two segments, which is why it needs no key and why anyone holding a token can read its contents. Verification is a genuinely different operation requiring the shared secret for HMAC algorithms or the public key for RSA and ECDSA, and this tool deliberately does not attempt it rather than implying a check it cannot perform. Everything happens in your browser with no network request, which matters because a live token is a working credential and pasting one into a remote service hands it over.
JWT Decoder vs. traditional online converters
| Feature | JWT Decoder (in-browser) | Traditional online converters |
|---|---|---|
| File upload required | No - never leaves your device | Yes - file is sent to a server |
| Processing queue | None - starts instantly | Often, especially at peak times |
| Watermark on output | Never | Common on free plans |
| Usage limits | None - free, unlimited use | Often capped per day or file size |
| Works offline once loaded | Yes, for most tools | No - requires a live connection |
| Account required | No | Often, for anything beyond a trial |
Who uses JWT Decoder
Debugging authentication failures
Check whether a token has expired or carries the claims your API expects.
Inspecting API integration tokens
See what an identity provider is actually issuing when wiring up a login flow.
Verifying permission claims
Confirm the roles or scopes encoded in a token match what a user should have.
Learning how JWTs work
See the header, payload and signature structure directly rather than reading about it.
Frequently asked questions
Does this verify the token’s signature?
No, verifying a signature requires the secret (HMAC) or public key (RSA/ECDSA) used to sign it - this tool only decodes the publicly visible header and payload.
Is my token sent to a server?
No, decoding happens entirely in your browser using standard Base64URL decoding - nothing is transmitted.
Why would decoding fail?
If the pasted text isn’t a valid JWT (three dot-separated Base64URL-encoded parts) or the payload isn’t valid JSON, decoding will show a clear error.
Is it safe to put sensitive data in a JWT?
No, and this is the misunderstanding worth correcting. A JWT is signed, not encrypted. Anyone holding the token can read its payload with no key at all, exactly as this tool does. The signature proves the contents have not been altered; it does nothing to hide them. Never put passwords, personal data or secrets in a payload.
How do I check if a token has expired?
Look at the exp field in the decoded payload. It is a Unix timestamp in seconds, counted from 1 January 1970, so it looks like a large number rather than a date. An expired token is the single most common cause of an authentication failure that appears to have no explanation.
What are the standard payload fields?
The common registered claims are sub for the subject or user, iss for the issuer, aud for the intended audience, exp for expiry, iat for issued-at, and nbf for not-valid-before. Anything else is defined by whoever issued the token.
Is pasting a real token here risky?
Not with this tool, since nothing is transmitted and you can confirm that in your browser’s network tab. Pasting a live production token into an arbitrary online decoder is genuinely risky, because a valid token is a working credential for as long as it lasts.