Free Online JWT Decoder & Encoder

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It's commonly used for authentication and information exchange. A JWT consists of three parts: Header, Payload, and Signature, separated by dots.

Yes, completely safe. This JWT decoder runs entirely in your browser using client-side JavaScript. Your tokens never leave your device or get uploaded to any server, ensuring complete privacy and security.

Simply paste your complete JWT token string into the input area and click the "Decode" button (or enable realtime mode for automatic decoding). The decoder will parse the token and display each part with syntax-highlighted JSON formatting.

The JWT header is a JSON object that contains metadata about the token. It typically includes two fields: "alg" (the signing algorithm such as HS256, RS256, or ES256) and "typ" (the token type, usually "JWT"). The header is Base64Url encoded to form the first part of the JWT.

The JWT payload contains the claims — statements about an entity (typically the user) and additional data. Common claims include: sub (subject), iat (issued at), exp (expiration), iss (issuer), aud (audience), and nbf (not before).

The JWT signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed. It's created by signing the encoded header and payload with a secret key using the algorithm specified in the header.

This decoder automatically reads the "exp" (expiration time) and "nbf" (not before) claims from the payload and compares them with the current system time. Valid tokens are highlighted in green with remaining validity time displayed.

Yes! Switch to the "Encode" tab to create and sign JWT tokens. You can customize the header and payload JSON, select from multiple signing algorithms (HS256, HS384, HS512, or none), enter your secret key, and optionally add standard claims.

This tool decodes the header and payload of any JWT without needing the secret. However, signature verification requires the secret key. For HMAC-signed tokens (HS256/HS384/HS512), use the verification tool with your secret:

const jwt = require("jsonwebtoken");\nconst decoded = jwt.verify(token, "your-secret");\nconsole.log(decoded); // { sub: "123", name: "John" }

For RS256/ES256 (asymmetric algorithms), you need the public key. Note that signature verification is displayed when you provide the key, while header/payload decoding works without any key.

JWT and JWS are closely related but not identical. JWS (RFC 7515) is a mechanism for signing arbitrary content, producing a compact serialization of header + payload + signature. JWT (RFC 7519) is a specific use case of JWS that requires the payload to be a JSON claims set with registered claim names like exp and sub. Every JWT is technically a JWS, but not every JWS is a JWT — JWS can sign any binary payload. The JWT specification adds constraints on what the payload must contain.

For web applications, store JWTs in an httpOnly secure SameSite cookie rather than localStorage or sessionStorage. Cookies with the httpOnly flag cannot be accessed by JavaScript, preventing XSS attacks from stealing the token. localStorage is accessible via any JavaScript executing on the same origin, making it vulnerable to XSS. The trade-off is that cookie-based storage requires CSRF protection, while localStorage-based storage requires careful XSS prevention. For mobile apps, use the platform-native secure key storage (Keychain on iOS, Keystore on Android).

If a JWT has no exp (expiration) claim, the token never expires according to the JWT specification. Most security-conscious applications should reject tokens without an expiration time during validation. The exp claim is a registered claim (recommended but not mandatory per RFC 7519), meaning servers must explicitly check for it. Security frameworks like Spring Security and Auth0's JWT libraries often enforce exp by default. Always include an exp claim in tokens you generate and validate it on the server side.

HS256 uses a single shared secret key for both signing and verification — anyone with the secret can both create and verify tokens. RS256 uses a private key to sign and a public key to verify, enabling third-party verification without exposing signing capability. RS256 is preferred for microservice architectures where the auth service signs tokens and other services only need the public key to verify them. HS256 is simpler but requires the secret to be shared with every service that needs to verify tokens, increasing the risk of secret exposure.