JWT Decoder & Encoder
Decode, Verify & Create JWTs

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts: header, payload, and signature, separated by dots. JWTs are commonly used for authentication and information exchange.

A JWT consists of three Base64-URL encoded parts separated by dots: the header (contains algorithm and token type), the payload (contains claims and user data), and the signature (cryptographic hash of header + payload + secret). Together they form the structure: header.payload.signature.

HttpOnly cookies are generally more secure than localStorage for storing JWTs. localStorage is vulnerable to XSS attacks where malicious JavaScript can steal tokens. HttpOnly cookies cannot be accessed by JavaScript, providing better protection. Use the Secure flag for HTTPS-only transmission and SameSite attribute to prevent CSRF attacks.

JWT security comes from the cryptographic signature, not encryption. While anyone can decode the payload, they cannot modify it without invalidating the signature. The signature verifies that the token was issued by your server and hasn't been tampered with, ensuring data integrity and authenticity.

Decoding simply Base64-decodes the header and payload to read the data - anyone can do this without the secret. Verifying checks the cryptographic signature using the secret key to ensure the token is authentic and hasn't been tampered with. Always verify tokens on the server before trusting their contents.

Yes! All decoding and verification happens entirely in your browser using JavaScript. Your tokens and secrets never leave your device and are not sent to any server. This tool is safe for inspecting production tokens.

JWTs are signed but not encrypted by default. Anyone who intercepts the token can decode and read the payload (as this tool demonstrates). Never store passwords, credit card numbers, or other sensitive information in JWT payloads. For sensitive data, use encrypted JWTs (JWE) or keep data server-side.

Common JWT vulnerabilities include algorithm confusion attacks (switching RS256 to HS256), the "alg: none" vulnerability, weak secret keys vulnerable to brute-force, token theft via XSS or man-in-the-middle attacks, and missing expiration validation. Always validate the algorithm, use strong secrets, set expiration times, and verify tokens server-side.

Store JWTs in HttpOnly cookies instead of localStorage to prevent JavaScript access. Implement Content Security Policy (CSP) headers to block unauthorized scripts. Sanitize all user inputs to prevent XSS injection. Use short token expiration times and implement refresh token rotation to limit damage if tokens are compromised.

This tool supports HMAC-based algorithms (HS256, HS384, HS512) for signature verification. RSA (RS256, RS384, RS512) and ECDSA (ES256, ES384, ES512) require a public key and are not currently supported for verification in this browser-based tool.

This tool only supports HMAC algorithms (HS256, HS384, HS512) for token creation. For RSA or ECDSA signatures, you need a private key and should use proper JWT libraries like jsonwebtoken (Node.js), PyJWT (Python), or jose (multiple languages).

While you can technically modify a decoded JWT's payload, doing so will invalidate the signature. The server will reject the modified token during verification since the signature no longer matches. To modify claims, you must generate a new token with the secret key.

The expiration timer shows a live countdown until the token expires based on the "exp" claim. If the token is already expired, it will show "Expired" in red. Tokens without an expiration claim will show "No expiration claim".

No, it's cryptographically impossible to extract the secret key from a JWT. The signature is created using a one-way hashing algorithm, which means you cannot reverse it to obtain the original secret. However, weak secrets can be vulnerable to brute-force attacks, so always use strong, random keys.

The "alg: none" vulnerability occurs when JWT libraries accept tokens with the algorithm set to "none", effectively allowing unsigned tokens. An attacker can modify the payload and remove the signature entirely. Modern JWT libraries have patched this, but always explicitly validate the expected algorithm server-side and reject "none" algorithms.