JWT Decoder

About JWT (JSON Web Tokens)

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64Url-encoded parts separated by dots: a Header (algorithm and token type), a Payload (claims about the user or session), and a Signature (cryptographic proof of integrity). JWTs enable stateless authentication — the server doesn't need to store sessions, making them ideal for distributed systems and microservices.

Security Warning

JWTs are only Base64Url-encoded, not encrypted. Anyone with the token can read its contents. Never store passwords, credit card numbers, or other sensitive data in a JWT payload. Use HTTPS to prevent interception in transit.

The Three Parts of a JWT

• Header: Contains metadata — the signing algorithm (e.g. HS256, RS256) and token type (JWT). This tells the server how to verify the signature.
• Payload: Contains the claims — key-value pairs like sub (subject/user ID), iat (issued at), exp (expiration), and any custom data your application needs.
• Signature: Created by signing the encoded header and payload with a secret key (HMAC) or private key (RSA/ECDSA). This prevents tampering — if anyone modifies the payload, the signature check fails.

Signing vs. Encryption

• JWS (JSON Web Signature): The standard JWT format. Like a postcard with a tamper-proof seal — anyone can read the content, but nobody can modify it without breaking the seal. Provides integrity and authentication.
• JWE (JSON Web Encryption): An encrypted JWT format. Like a locked safe — only the intended recipient with the decryption key can read what's inside. Provides confidentiality on top of integrity.
• Nested JWT: A JWS wrapped inside a JWE (or vice versa) for both signing and encryption. Used when you need to guarantee both who sent it and that nobody else can read it.

Common Signing Algorithms

• HS256 (HMAC + SHA-256): Symmetric — the same secret key signs and verifies. Simple and fast, best when both parties are trusted (e.g. a single backend service).
• RS256 (RSA + SHA-256): Asymmetric — a private key signs, a public key verifies. Ideal when third parties need to verify tokens without access to the signing key.
• ES256 (ECDSA + SHA-256): Asymmetric with elliptic curves — smaller keys and faster than RSA for equivalent security. Increasingly popular in modern systems.
• EdDSA (Ed25519): High-performance asymmetric algorithm with small signatures. Gaining adoption for its speed and strong security properties.

Standard JWT Claims

• iss (Issuer): Identifies who issued the token (e.g. your auth server URL).
• sub (Subject): Identifies the principal/user the token represents.
• aud (Audience): Intended recipient(s) of the token (e.g. your API domain).
• exp (Expiration): Unix timestamp after which the token is no longer valid.
• nbf (Not Before): Unix timestamp before which the token should not be accepted.
• iat (Issued At): Unix timestamp of when the token was created.
• jti (JWT ID): Unique identifier for the token, useful for preventing replay attacks.

Security Best Practices

• Always validate the signature before trusting a JWT's contents
• Check the exp claim and reject expired tokens
• Validate iss and aud claims to prevent token misuse across services
• Use short-lived access tokens (5-15 minutes) with refresh tokens for long sessions
• Store tokens securely — prefer HttpOnly cookies over localStorage to mitigate XSS
• Always transmit JWTs over HTTPS to prevent interception
• Never use the none algorithm in production — always require a valid signature
• Rotate signing keys periodically and support key ID (kid) for graceful rotation

Common Use Cases

• User authentication in web and mobile applications
• API authorization between microservices
• Single sign-on (SSO) across multiple domains
• OAuth 2.0 access tokens and OpenID Connect ID tokens
• Securely transmitting claims between parties in webhooks or event-driven systems

Häufig gestellte Fragen (FAQ)