JWT Decoder

About JWT Decoder

JSON Web Tokens (JWTs) are compact, URL-safe tokens used to transmit signed claims between two parties. The token is three dot-separated Base64URL-encoded strings: a header that describes the algorithm, a payload containing the claims, and a signature that proves the token was not tampered with. The JWT Decoder splits the token, base64-decodes each part, and pretty-prints the JSON. The signature is shown but not verified — verification requires either the HMAC secret (for symmetric algorithms) or the public key (for asymmetric algorithms), and pasting a real production secret into a public webpage is a security mistake.

Anatomy of a JWT

Each JWT has three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The first part is the header. Decoded, it is {"alg":"HS256","typ":"JWT"} — the algorithm used for signing (in this case HMAC-SHA256) and the token type. The second part is the payload. Decoded, it is {"sub":"1234567890","name":"John Doe"} — the claims, which are arbitrary JSON. The third part is the signature, computed as HMAC-SHA256(secret, base64url(header) + "." + base64url(payload)). The signature is 256 bits for HS256, encoded as 43 Base64URL characters.

Base64URL Encoding

JWTs use Base64URL, not regular Base64. The differences are small:

• + becomes -
• / becomes _
• Padding = characters are stripped

These substitutions make the encoding URL-safe (no characters that need to be percent-encoded) and remove the need for padding (because the trailing equals signs are unnecessary for unambiguous decoding). The resulting string can be used directly in a URL, in a header, or in a cookie without further encoding. The Base64 Encoder supports the standard alphabet; this decoder handles Base64URL automatically.

Standard Claims

The payload can contain any JSON, but a set of registered claims is common enough to be standardized by RFC 7519:

• iss (issuer) — who issued the token. Useful for distributed systems where multiple services issue tokens.
• sub (subject) — the principal the token is about, typically a user ID.
• aud (audience) — the intended recipient. The token should be rejected if the audience does not match the verifying service.
• exp (expiration) — Unix timestamp after which the token must be rejected.
• nbf (not before) — Unix timestamp before which the token must be rejected.
• iat (issued at) — Unix timestamp when the token was issued.
• jti (JWT ID) — a unique identifier for the token, used to prevent replay attacks.

Common Algorithms

• HS256 (HMAC-SHA256) — symmetric. The same secret is used to sign and verify. Standard for tokens that never leave a single trust boundary (a backend service issuing for itself).
• HS384 and HS512 — HMAC with SHA-384 or SHA-512. Same secret model, larger hash output.
• RS256 (RSA-SHA256) — asymmetric. The issuer signs with a private key; the verifier checks with a public key. Standard for tokens issued by an identity provider that the relying party does not fully trust.
• ES256 (ECDSA-SHA256) — asymmetric with elliptic curves. Smaller signatures than RS256 for the same security level.
• EdDSA (Ed25519) — asymmetric, fast and small. Increasingly standard for new systems.
• none — no signature. Never use this in production; it is a footgun that has caused many vulnerabilities.

Why This Tool Does Not Verify Signatures

Verifying a JWT signature requires either the HMAC secret (for symmetric algorithms) or the public key (for asymmetric algorithms). The HMAC secret is, by definition, the same secret used to issue the token — it is the most sensitive credential in the entire authentication system. Pasting it into a public website, even over HTTPS, defeats the purpose of having a secret. The JWT Decoder shows you the token structure but not the verification status.

If you need to verify a token, do it in your application code with a JWT library that you control. Every major language has one: jsonwebtoken in Node.js, PyJWT in Python, JWT in Go, jjwt in Java, System.IdentityModel.Tokens.Jwt in .NET. The standard library is preferable to a website because the secret never leaves your process.

Security Pitfalls

• alg: none — accepting tokens with the algorithm set to none allows anyone to forge tokens. Always reject this algorithm explicitly.
• Algorithm confusion — a service that expects RS256 (verified with a public key) but accepts HS256 (verified with the public key as the HMAC secret) is vulnerable. The attacker submits an HS256 token signed with the public key — which is, by definition, public. Always pin the expected algorithm.
• Missing expiration — tokens without an exp claim are valid forever. If the token is compromised, the attacker has permanent access. Always include exp.
• Pasting tokens into public tools — any token pasted into a third-party JWT decoder is exposed to that service. For sensitive tokens, run the decoder locally or use the offline tools in your development environment.

Frequently Asked Questions