Decode and inspect any JWT

Paste a JSON Web Token below to decode its header, payload, and signature. We'll check for expiration, algorithm weaknesses, and sensitive data exposure.

100% private — your token never leaves your browser
Please paste a JWT to decode.

Header
Payload
Signature

PhishClean detects JWT tokens leaking in URLs and browser storage — in real time.

The extension monitors every page you visit automatically, catching threats this decoder can't detect.

JWTs exposed in URLs and query strings
Auth headers sent to third-party domains
API keys and secrets in source code
Password fields on phishing pages
HTTPS downgrade attacks
Hidden iframes stealing credentials
Install PhishClean Free

Frequently asked questions

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and information exchange between parties. It consists of three Base64URL-encoded parts separated by dots: a header (specifying the signing algorithm and token type), a payload (containing claims like user identity, permissions, and expiration time), and a signature (used to verify the token hasn't been tampered with). JWTs are widely used in OAuth 2.0, OpenID Connect, and API authentication flows.

Is my token stored or sent anywhere?

No. The JWT you paste is decoded entirely inside your browser using JavaScript. It is never transmitted to PhishClean or any third-party server. You can verify this yourself: open your browser's developer tools, switch to the Network tab, and paste a token. You will see zero outbound requests during decoding. We built it this way because a JWT decoder that collects tokens would be a serious security vulnerability.

What security issues can this tool detect?

This tool checks for several common JWT security issues: expired tokens, unsigned tokens using the "none" algorithm (a critical vulnerability that allows token forgery), weak symmetric algorithms like HS256 (where anyone with the secret can forge tokens), sensitive personally identifiable information in claims (like email addresses, passwords, SSNs, or credit card numbers), excessively long expiration windows (over 30 days), and missing standard security claims like issuer (iss) and expiration (exp).

Why shouldn't JWTs be in URLs?

JWTs in URLs are a serious security risk because URLs are recorded in many places: browser history, server access logs, analytics platforms, CDN and proxy logs, and HTTP Referer headers sent to other sites. Anyone with access to these logs can extract the token and potentially impersonate the user or access protected resources. JWTs should be transmitted in HTTP Authorization headers (Bearer tokens) or secure, HTTP-only cookies — never in query strings, URL fragments, or path segments.