JWT Decoder & Local Verifier

You can use this 100% browser-side JWT Decoder. It parses the Base64Url-encoded header and payload of your token directly in your browser's memory using JavaScript's native encoding utilities. No data is transmitted to any server, making it completely safe for decoding production tokens.

No. This tool operates on a zero-knowledge architecture. It does not use localStorage, sessionStorage, IndexedDB, cookies, telemetry, or analytics inside the tool. Everything stays in your browser's volatile memory and is permanently lost as soon as you close or refresh the tab.

To verify an asymmetric signature (like RS256 or ES256), paste your token into the input area, then scroll to the 'Local Signature Verification' panel. Choose 'Public Key', paste your PEM-encoded (SPKI or PKCS#1) or JWK public key, and the tool will use the browser's native Web Crypto API (`crypto.subtle.verify`) to cryptographically validate the signature without uploading it.

The payload (claims section) contains JSON-formatted key-value pairs representing user details and authorization data. Common claims include the issuer (`iss`), subject/user ID (`sub`), audience (`aud`), expiration (`exp`), and custom scopes, roles, permissions, names, or emails. While these are Base64Url-encoded, they are not encrypted, meaning anyone with access to the token can read them.

Yes, it is entirely safe. Because this tool runs 100% client-side with zero external API calls or network requests, your production JWTs, private claims, and secrets remain securely inside your local browser sandbox. This stands in stark contrast to online debuggers that send your inputs to backend servers.

This local verifier supports symmetric algorithms: HS256, HS384, and HS512 (HMAC), as well as asymmetric algorithms: RS256, RS384, and RS512 (RSA-SHA), and ES256, ES384, and ES512 (ECDSA). Cryptographic verification is handled by standard browser engines via the Web Cryptography API.

Clock skew is the time difference between the server that generated the JWT and the client validating it. This tool lets you adjust a slider (from -300s to +300s) to simulate client-side clock differences. This helps test how systems behave when their clocks are slightly out of sync with your authentication provider.

For HMAC algorithms like HS256, the security of the signature relies entirely on the secrecy and complexity of the key. If the key is too short or uses common words, it is vulnerable to brute-force attacks. Our analyzer detects keys shorter than the algorithm's block size or keys matching dictionary lists, alerting you to upgrade.

JSON Web Signature (JWS) is the RFC 7515 standard that defines a JSON structure with a cryptographically signed payload. JSON Web Token (JWT) is the RFC 7519 standard that uses the JWS structure specifically to represent claims. A signed JWT is practically a JWS where the payload contains claims like issuer and subject.

Yes. Once the page is loaded, the entire application logic is cached in browser memory. You can disconnect from the internet or run it in an offline environment, and it will decode, parse JSON, run security audits, and verify cryptographic signatures with full functionality.

It uses robust try-catch blocks around the Base64Url decoder and JSON parser. If a token is malformed, has invalid characters, or is missing sections, the tool displays a clean, user-friendly error message detailing what is wrong (e.g. 'Malformed JWT: Missing signature part') without crashing the interface.

Algorithm confusion is a security vulnerability where a JWT library is tricked into using a symmetric algorithm (like HS256) to verify a signature that was signed with an asymmetric algorithm (like RS256). The attacker signs the token using the public key as the HMAC secret. This tool flags when asymmetric tokens are checked using HMAC keys.

No, standard JWTs (JSON Web Signatures) are signed but not encrypted. The header and payload are simply Base64Url-encoded JSON strings. Anyone who intercepts the token can decode and view the claims. If you need confidentiality, you must use JSON Web Encryption (JWE) or encrypt the payload before signing.

The 'none' algorithm indicates that the JWT is unsigned. Many early JWT libraries had a vulnerability where they automatically trusted tokens signed with 'none' even if a signature was expected. Attackers could simply bypass security by changing the header `alg` to `none` and stripping the signature. The tool flags this as a critical warning.

Yes, this tool includes a Token Diff Viewer. You can paste a primary JWT and a comparison JWT to view their headers and payloads side-by-side, highlighting added, modified, or deleted claims. This is perfect for debugging token issuance changes.