JWT Decoder and Verifier

A JSON Web Token (RFC 7519) is a set of claims, facts such as who the user is and when access ends, packed into a string that is safe to put in a URL or an HTTP header. The common form is a JWS (JSON Web Signature, RFC 7515): three Base64url parts joined by dots.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.bdUV6fzqg02cO5s8BpihQT_xT_PCKCv21ZGrR8WLDAc
└──── header ──────┘ └──────── payload ────────┘ └─────────────── signature ───────────────┘

That token decodes to the header {"alg":"HS256"} and the payload {"sub":"1234567890"}. Paste it into the decoder with the secret playxoft-demo-secret-not-for-prod-01 and the signature verifies; change a single character and it fails.

A JWT is signed, not encrypted. Base64url is an encoding that anyone can reverse, and that is all a decoder does before it checks the signature. The signature only proves that the token came from someone holding the key and that it has not been modified since. So never put passwords, payment details or other secrets in a JWT payload.

If the claims themselves must stay confidential, use an encrypted JWE (RFC 7516). A JWE has five parts instead of three; paste one here and the tool reads its header and tells you which algorithms it uses.

The signature covers the exact characters header.payload: the two Base64url strings and the dot between them. A verifier recomputes it with the key and compares. Change one character of the payload and the check fails, which is why nobody can edit a claim without the key.

A token is only trustworthy after all of these checks pass (RFC 8725, JWT Best Current Practices):

1. Algorithm: accept only the algorithm you expect for that key. Never let the token's own alg decide.
2. Signature: verify with the issuer's secret or public key, usually fetched from its JWKS endpoint and picked by kid.
3. Time: reject the token if now is at or after exp, or before nbf, allowing only a small clock-skew leeway.
4. Issuer and audience: iss must be the issuer you trust and aud must name your API.
5. Your own rules: scopes, roles, the token type in typ, or a revocation list keyed by jti.

This tool covers the first three. The badges show the validity window by your clock, and the Verify signature panel runs the cryptography with the browser's Web Crypto API, so the key never leaves the page.

Choose an asymmetric algorithm (RS, PS, ES or Ed25519) as soon as a second service needs to verify tokens. With HMAC, every service that can verify a token can also forge one.

RFC 9864 (2025) deprecates the generic EdDSA alg in favor of the fully specified Ed25519. Many libraries still emit EdDSA, and this tool verifies and signs both.

If you do use HMAC, generate the secret randomly. A short, human-chosen secret like secret123 can be cracked offline from a single captured token, because the attacker can test guesses against the signature at full speed without ever touching your server. The Generate secret button in the encoder creates a random secret of the right length.

ECDSA has one interoperability trap: JOSE requires the raw R||S signature (64 bytes for ES256, 96 for ES384, 132 for ES512), while OpenSSL and Java's SHA256withECDSA produce ASN.1 DER by default (.NET's ECDsa.SignData already returns the raw form). This tool detects DER signatures, verifies them anyway and warns you, because strict libraries will reject them.

RFC 7519 registers seven claims. All are optional, but most APIs require exp, iss and aud.

The three time claims are NumericDate values: seconds, not milliseconds, since 1970-01-01 UTC. For example 1767225600 is 2026-01-01 00:00:00 UTC. A 13-digit value is almost always the bug of writing Date.now() instead of Math.floor(Date.now() / 1000), and the decoder flags it.

Identity providers add more, such as email, nonce and auth_time from OpenID Connect, or scope, client_id and roles from the JWT access-token profile (RFC 9068). The claims table explains the common ones and marks the rest as custom.

• Accepting `alg: none`. An unsigned token proves nothing. Anyone can write one, so servers must reject it.
• Algorithm confusion. If a server lets the token choose alg and verifies with whatever key it has, an attacker can sign an HS256 token using the server's RSA *public* key as the HMAC secret. Pin one algorithm per key.
• Weak HMAC secrets. Short or guessable secrets fall to offline brute force. Use random bytes at least as long as the hash.
• Skipping `aud` and `iss` checks. A token your identity provider issued for a different app would otherwise be accepted by yours.
• Trusting `jku`, `x5u` or an embedded `jwk`. Fetching the verification key from a URL inside the token lets an attacker supply their own key. Use a fixed JWKS URL.
• Long lifetimes without revocation. A stolen JWT works until it expires. Keep access tokens short-lived and rotate them with refresh tokens, or keep a denylist of revoked jti values.
• Sensitive data in the payload. Everything in it is readable by anyone who sees the token, including browser extensions and logs.

Use a maintained library and always pass the expected algorithm, issuer and audience:

// JavaScript / TypeScript (jose)
import { createRemoteJWKSet, jwtVerify } from "jose";
const jwks = createRemoteJWKSet(new URL("https://auth.example.com/.well-known/jwks.json"));
const { payload } = await jwtVerify(token, jwks, {
  algorithms: ["RS256"],
  issuer: "https://auth.example.com",
  audience: "https://api.example.com",
});

# Python (PyJWT)
import jwt
claims = jwt.decode(token, public_key_pem, algorithms=["RS256"],
                    audience="https://api.example.com", issuer="https://auth.example.com")

// Go (github.com/golang-jwt/jwt/v5)
token, err := jwt.Parse(raw, func(t *jwt.Token) (any, error) { return rsaPublicKey, nil },
    jwt.WithValidMethods([]string{"RS256"}),
    jwt.WithIssuer("https://auth.example.com"),
    jwt.WithAudience("https://api.example.com"))

// C# (Microsoft.IdentityModel.JsonWebTokens)
var result = await new JsonWebTokenHandler().ValidateTokenAsync(token, new TokenValidationParameters {
    ValidAlgorithms = new[] { SecurityAlgorithms.RsaSha256 },
    ValidIssuer = "https://auth.example.com",
    ValidAudience = "https://api.example.com",
    IssuerSigningKey = new RsaSecurityKey(rsa),
});
if (!result.IsValid) { /* reject */ }

Decoding without verifying, as jose's decodeJwt or PyJWT's verify_signature: False option do, is fine for debugging or for showing a user's name in a browser app. Never make an access decision on a token you have only decoded.