JWT Decoder parses a JSON Web Token into its three base64url-encoded parts: header, payload, and signature. The header and payload are displayed as formatted JSON. The expiration field (exp) is shown as a human-readable date with a Valid or Expired badge. Note: signature verification is not possible client-side.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
No. Signature verification requires the secret key (HMAC) or public key (RSA/ECDSA) used to sign the token, which isn't available client-side. This tool decodes and displays the contents but does not verify authenticity.
JWT payloads are base64url-encoded, not encrypted, so anyone with the token can read its contents. Treat tokens as sensitive — prefer pasting expired tokens or tokens from non-production environments.
A JWT has three base64url-encoded parts separated by dots: the header (algorithm and token type), the payload (claims/data), and the signature (used to verify integrity).
exp is the expiration time, a Unix timestamp after which the token should be considered invalid. The tool converts this to a human-readable date and shows a Valid or Expired badge.
Some servers don't strictly enforce the exp claim, or use a grace period. The Expired badge reflects only the exp value compared to the current time, not your server's actual validation logic.
The tool expects the standard three-part dot-separated JWT structure. Other token formats (opaque tokens, API keys) won't decode meaningfully.
Nested objects and arrays in the payload are displayed as formatted, indented JSON for readability.