A free JWT decoder and an HTTP security header analyzer, neither of which transmits what you paste, plus the toolkit behind every manual SaaS and API security review I run.
Paste a JSON Web Token and its header and payload are rendered as readable JSON. The tool then checks what it finds: the signing algorithm, key headers such as kid and jku, expiry and lifetime, audience and issuer, sensitive data in the claims, and authorization claims a server might trust without checking. Each weakness comes with why it matters and how to test it. Decoding happens in your browser, and the token is never sent anywhere.
Nothing leaves this page. Decoding happens in your browser. No token is sent anywhere, logged or stored.
A JSON Web Token has three parts separated by dots: a header, a payload and a signature. The header and payload are JSON encoded with base64url. That is an encoding, not encryption. Anyone holding the token can decode every claim without any key.
The signature proves integrity. If the server verifies it properly, nobody can change a claim without the change being detected. It hides nothing. A signed token is tamper evident, not confidential.
A subject identifier, the issuer, the audience, issued at and expiry times, and perhaps a token or key identifier. Stable, non sensitive values the server needs on every request.
Passwords, API keys, personal data you would not want printed in a log, and anything that helps an attacker once disclosed. Tokens end up in browser storage, server logs, analytics tools and support tickets, so assume every claim will be read by someone it was not meant for.
A role, scope or tenant claim is fine as a hint, but the server has to confirm it against its own records before anything sensitive happens. When the server trusts the token alone, a stale or overly broad claim turns into privilege escalation. Checking that the server re-validates these claims is a core part of authorization testing. That is why token handling gets tested as part of API security testing and access control review, not as a cryptography exercise.
These are the issues the decoder reports, and why each one matters.
A server built for RS256 that also accepts HS256 may verify an HMAC token using the RSA public key as the secret. The public key is public, so anyone can then sign whatever claims they like. Pin the expected algorithm on the server instead of reading it from the header.
The JWT specification allows an unsecured token with alg set to none. A server that honours it accepts tokens with no signature at all, including case variants such as None. Testing it takes seconds: remove the signature and replay the request.
The kid header tells the server which key to verify with, and it is read before the signature is checked. If the server feeds it into a file path, a database query or a shell command, it becomes an injection point. Treat it as untrusted input and match it against a fixed set of known keys.
These headers point the server at a URL to fetch a verification key or certificate from. A server that follows them without an allowlist will fetch an attacker's key and accept an attacker's tokens. Ignore them, or pin the hosts they may name.
A JWT stays valid until it expires, whatever happens to the account in the meantime. A missing or very long exp means a leaked token keeps working after a password reset or an offboarding. Short lived access tokens with a server controlled refresh flow restore a point where access can be withdrawn. The API security checklist in the security resources library covers token lifecycle and revocation in more detail.
aud says which service a token is meant for, and iss says who minted it. Without both checks, a token issued for one internal service can be replayed against another that trusts the same key or identity provider. Each API should reject tokens that were not issued for it.
Claims such as role, scope, tenant_id or is_admin record what the user could do when the token was issued. If the user is downgraded, moved or removed, the token says otherwise until it expires. Sensitive actions should check current permissions on the server, because trusting the claim is the same mistake behind much of broken access control.
Tools find surface. Judgment finds the bug. Here is what actually gets used, and what each one is for.
The centre of every engagement. Repeater for replaying a request as a second account, Intruder for object identifier sweeps, and the session handling rules that keep two roles authenticated at once.
Example: a viewer replays an admin's export request and gets the full customer CSV, because the export endpoint checks that a session exists but never checks its role.
Subdomain enumeration, certificate transparency, and endpoint discovery from client bundles, to find the hosts and routes that never made it into the inventory.
Example: a staging API on an old subdomain still accepts production logins and exposes debug routes that the production build removed.
Introspection where it is open, schema reconstruction where it is not, then walking every mutation and resolver against each role rather than trusting the documentation.
Example: a mutation the interface never calls lets any member change their own role to owner, because the resolver never checks who is asking.
A scanner can tell you an endpoint exists. It cannot tell you that invoice 5521 belongs to a different customer, because the response looks completely normal. Every finding in a manual penetration test report is reproduced by hand before it counts.
Example: the scanner marks the invoice endpoint healthy. The 200 it returned to the wrong tenant is the finding.
Most engagements need something that does not exist yet: a differ for two roles' responses, a race condition harness, a token replay loop. Written for the job, thrown away after.
Example: twenty parallel requests redeem a single use credit four times, because the balance check and the update are not atomic.
Not available yet. Listed so you know what is coming, not as something you can use today.
Track subdomains, exposed services and forgotten endpoints over time, with ownership context attached.
Map routes, roles and object ownership so an authorization review has structure instead of a spreadsheet.
Organize evidence, reproduction steps and retest status into something an engineering team can act on.
Only if the decoder never sends it anywhere. A live token is a credential: whoever holds it can act as that user until it expires. This tool runs entirely in your browser and makes no request with the token, but with any tool, the safer habit is an expired or test token.
A standard signed JWT is not encrypted, so there is nothing to decrypt. The header and payload are base64url, and anyone can decode them. What cannot be done without the key is producing a valid signature. Encrypted tokens (JWE) do need the recipient's key to read, but they are far less common in APIs.
A session cookie usually holds a random identifier that the server looks up on every request, so it can end a session instantly. A JWT carries its own state and is verified without a lookup, which scales easily but makes revocation harder. A JWT can also be stored in a cookie, so the real difference is where the state lives, not how it travels.
Rarely against mainstream libraries, which reject it by default. It still appears in custom verification code, older dependencies and services that decode tokens without verifying them, so it stays on every JWT checklist.
Minutes, not days. Fifteen minutes to an hour is common for access tokens, paired with a longer lived refresh token that the server can revoke. The right figure depends on how quickly a removed user needs to lose access.
Not directly, because the server accepts it without looking anything up. The practical options are short expiry, a denylist of token IDs (the jti claim) checked on each request, rotating the signing key, or a per user token version the server compares.
Join the waiting list for the tools above, or skip the wait and ask for a manual review of your product now.
