JWT Decoder & Validator

For reading a token, the decoder displays the algorithm from the header for every standard type — the HMAC family (HS256, HS384, HS512), RSA (RS256, RS384, RS512), ECDSA (ES256, ES384, ES512), RSA-PSS (PS256, PS384, PS512), and the unsecured "none" algorithm. Decoding works regardless of algorithm because reading the header and payload only requires Base64URL decoding, not the signing key. The algorithm field matters most when you move on to verifying or signing a token. For guidance on which algorithms are actually secure to use, see the linked deep-dive.

Often, yes. Base64URL is case-sensitive, so a token that was forced to lowercase somewhere along the way (some logging pipelines, URL handlers, or databases do this) is normally corrupt and will not decode. This tool includes a lowercase-base64 recovery step: when it detects an all-lowercase segment, it searches for the case combination that decodes to valid JSON and flags that the input was recovered. It is a best-effort heuristic — long random claim values may not be fully recoverable — but it rescues many tokens that other decoders reject outright. This recovery feature is unique to this tool and is not something the blog articles cover.

Decoding and verification are two different operations, and the decode view does exactly one of them: it reads the token. It shows you the header, payload, claims, and expiration status, but reading a token does not prove it is authentic or untampered — anyone can decode any JWT without a key. Treat decoded claims as untrusted input. To confirm a token genuinely came from your auth server and was not modified, you must verify the signature with the secret or public key on the server side. The linked guide walks through signature verification end to end.

Yes. Switch from the Decode tab to the Build tab to construct a token from scratch: set the header algorithm, add registered claims (iss, sub, aud, exp, iat) and your own custom claims, choose an expiration preset, and supply a secret (for HMAC) or a PEM private key (for RSA/ECDSA/PSS) to produce a signed token. Signing happens locally in the browser. This is handy for generating test tokens when debugging an auth flow, so you do not have to paste a real production token to reproduce an issue.

The decoder labels each claim it finds, but if you want the background on what registered claims like iss, sub, aud, exp, iat, nbf, and jti represent — and how custom public and private claims differ — read the dedicated claims explainer. Understanding the claim set is what lets you tell, at a glance in the decoded output, whether a token is scoped to the right audience or carries the roles your app expects.

After you paste a token, the decoder reads the exp claim (a Unix timestamp in seconds) and shows the token's expiration status — valid, expired, or not-yet-valid (nbf) — so you do not have to do the timestamp math by hand. Remember that an expired token shown here is informational only: enforcement still happens server-side when the token is verified. For how the exp claim works and how refresh strategies are built around it, see the expiration deep-dive.

A JWT is three Base64URL segments joined by dots: header.payload.signature. This tool decodes and displays the header (algorithm and token type) and the payload (your claims) as readable JSON, and shows the signature as the raw third segment because a signature is a cryptographic hash, not encoded data — it cannot be turned back into readable text, only verified. If a string you paste does not split into exactly three non-empty parts, it is not a well-formed JWT and the decoder will tell you so. If you are deciding whether JWTs are even the right token format for your use case, the linked article covers when to use them.