A JWT often looks like harmless machine text, which is why it is easy to paste into the first decoder that appears in search results. A live token can still contain user details, roles, internal IDs, or a credential that an attacker can replay. The safest decoder is one that never receives the token in the first place.
Inspect JWTs locally in your browser.
Decode headers and payloads, inspect claims, and test supported signatures without uploading the token.
Open the private JWT decoder →What a JWT actually contains
A JSON Web Token usually has three dot-separated parts: a header, a payload, and a signature. The header describes the token type and algorithm. The payload contains claims such assub, iss, aud, and exp. The signature helps a verifier detect tampering.
In the common signed format, the first two parts are Base64URL-encoded JSON. Encoding makes the token portable; it does not hide the contents. Do not put secrets in a normal JWT payload, and do not treat a decoded payload as trustworthy until the signature and claims have been checked.
Why online decoding can leak a token
A server-side decoder must receive the token to decode it. That creates more copies and more places to investigate: request logs, reverse proxies, analytics, error reports, browser history, and backups. HTTPS protects the connection between you and the service, but it does not prevent the service from seeing or retaining the token after it arrives.
A token may be short-lived, but that is not a reason to paste it into an unknown service. It can still expose personal data during its lifetime, and a stolen bearer token may be usable until it expires or is revoked. Use a redacted sample or a local decoder while debugging.
It is also worth remembering that a website's own backend is rarely the only place a pasted token can end up. Crash reporters and error-monitoring tools (Sentry-style services are a common example), third-party analytics scripts, and CDN or proxy logs sitting in front of the decoder can all capture request bodies without the site operator doing anything malicious — they are just logging traffic the way these tools normally do. That is a lot of places for a live session token to be sitting in plaintext, and none of them are places you can audit from the outside.
Decode and verify are different jobs
- Decode: parse the header and payload so you can inspect their JSON.
- Verify: check the signature with the expected algorithm and key.
- Validate: enforce issuer, audience, expiry, not-before, and application-specific rules.
A browser tool can help with inspection and controlled testing, but it is not a replacement for server-side authorization checks. Never grant access because a token merely looks valid in a UI.
A safer JWT debugging workflow
- Use a locally running or browser-local decoder for real tokens.
- Redact tokens before posting screenshots, tickets, or chat messages.
- Check the algorithm, issuer, audience, and expiry against your application configuration.
- Revoke or rotate a token immediately if you pasted it into a service you do not trust.
- Keep signature verification and authorization decisions in the application that owns the key.
JWTs themselves are defined in RFC 7519, and the signature mechanics that make a token verifiable (not encrypted — verifiable) come from RFC 7515. OWASP also has a good rundown of common JWT attack patterns worth reading if you are building anything that issues or verifies tokens. If you just need to inspect one right now without pasting it into a random website, our JWT decoder runs the whole thing locally in your browser.