JWT Decoder & Encoder

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe token format defined in RFC 7519. JWTs are widely used for authentication, authorization, and information exchange in modern web applications and APIs.

A JWT consists of three Base64url-encoded parts separated by dots: header, payload, and signature. The header specifies the signing algorithm and token type. The payload contains claims — statements about the user and metadata like expiration time. The signature ensures the token has not been tampered with.

How JWT Signatures Work

Symmetric algorithms (HS256, HS384, HS512) use a single shared secret for both signing and verification. They are simple and fast, making them suitable for internal services where both parties can securely share the key.

Asymmetric algorithms (RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512, Ed25519) use a private key to sign and a corresponding public key to verify. This is ideal for distributed systems where the verifier should not have signing capability — for example, an auth server signs tokens with its private key, and API servers verify them with the public key.

Standard JWT Claims

• iss (Issuer) — who created the token
• sub (Subject) — who the token represents (usually a user ID)
• aud (Audience) — the intended recipient
• exp (Expiration) — when the token expires (Unix timestamp)
• iat (Issued At) — when the token was created
• nbf (Not Before) — the token is not valid before this time
• jti (JWT ID) — unique identifier for the token

Security Best Practices

• Always verify signatures on the server before trusting any claims.
• Check expiration — reject expired tokens to prevent replay attacks.
• Use strong secrets — for HMAC algorithms, use at least 256 bits of entropy.
• Validate the alg header — never allow the “none” algorithm in production.
• Keep payloads small — JWTs are sent with every request; large tokens impact performance.
• Don’t store secrets in payloads — JWT payloads are Base64-encoded, not encrypted. Anyone can read them.
• Prefer short expiration times and use refresh tokens for long-lived sessions.

Common Use Cases

Authentication: After login, the server issues a JWT that the client sends with subsequent requests (typically in the Authorization: Bearer header). The server verifies the token instead of looking up a session in a database.

OAuth 2.0 & OpenID Connect: Access tokens and ID tokens are often JWTs. The ID token contains user profile claims, while the access token grants permissions to specific resources.

JWT vs. Session Cookies: Session cookies store a session ID on the server; JWTs are self-contained and stateless. JWTs scale better across multiple servers but cannot be individually revoked without additional infrastructure (token blocklists or short expiration with refresh tokens).

Supported Algorithms

This tool supports all major JWT signing algorithms: HMAC (HS256, HS384, HS512), RSA (RS256, RS384, RS512), RSA-PSS (PS256, PS384, PS512), ECDSA (ES256, ES384, ES512), and EdDSA (Ed25519). Keys can be provided in PEM or JWK format for asymmetric algorithms.

Related Guides

• JWT for Beginners: Understanding JSON Web Tokens
• JWT Security Best Practices for Web Developers
• JWT vs Session Tokens: Which Should You Use?
• How JWT Signatures Work: HMAC, RSA, and ECDSA