← all tools
// FREE TOOL
JWT decoder
Paste a JSON Web Token to read its header and claims, with the expiry rendered as a real date and the common configuration mistakes called out. Everything happens in your browser — the token is never sent anywhere.
Runs entirely in your browser. Nothing is sent anywhere — check the network tab.
What to look at first
The algorithm, then the lifetime. alg tells you whether the token can be trusted at all; exp tells you how long a stolen one stays useful. Almost every real-world JWT problem is one of those two, not something exotic.
Common questions
- Is it safe to paste a real token here?
- Safer than almost anywhere else, because the decoding happens in JavaScript on your machine and there is no request to send it anywhere. You can verify that rather than trust it: open your browser's network tab and watch nothing leave. That said, the habit is worth keeping — a JWT is usually a live credential, and most online decoders POST it to a server before showing you anything. Prefer a local tool, and if a token has been pasted somewhere you are unsure about, rotate it.
- Why can't it verify the signature?
- Verification needs the signing secret or public key, and this page deliberately never asks for one. A site that collects both your token and your signing key is collecting everything needed to forge tokens for your service. Decoding shows you the claims; verification belongs in your own code or a local library.
- What does alg:none mean and why is it flagged so hard?
- It means the token declares it has no signature. The header is attacker-controlled, so if a library trusts it, anyone can strip the signature, set alg to none, edit the claims to say they are an administrator, and be believed. Every mature JWT library refuses this by default now, but the flaw reappears whenever someone writes their own verification or passes an empty algorithm list.
- Is HS256 a problem?
- Not inherently, but it is symmetric — the same secret both signs and verifies. That is fine for one service talking to itself. It becomes a problem when several services need to validate tokens, because every one of them then holds a key that can also mint tokens. If more than one party verifies, asymmetric algorithms let you distribute a public key that cannot forge anything.
- The payload has personal data in it. Is that bad?
- Worth knowing about, at least. A JWT payload is base64, not encryption — anyone holding the token can read every claim, including the user, their email, their roles and anything else in there. Treat the payload as public, and keep anything genuinely sensitive server-side behind an opaque identifier.