JWT Decoder
Decode and inspect JWT (JSON Web Token) headers and payloads. Displays expiry, standard claims, and algorithm. No signature verification.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user-7a2b4c",
"name": "Alice Johnson",
"email": "[email protected]",
"role": "admin",
"iss": "https://auth.example.com",
"aud": "web-app",
"iat": 1772280478,
"exp": 1772287678
}SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The signature is displayed as-is (Base64URL). Signature verification requires the secret key or public key and is not performed here.
Algorithm: HS256
About this tool
JWT (JSON Web Token) is an open standard (RFC 7519) for transmitting claims between parties as a compact, URL-safe string. A JWT consists of three Base64URL-encoded segments separated by dots: a Header, a Payload, and a Signature. The Header specifies the signing algorithm (alg) and token type (typ). The Payload contains claims — statements about the subject and additional metadata. The Signature is computed over the header and payload using the algorithm and key specified in the header.
The Payload contains registered, public, and private claims. Registered claims are defined by the spec and have short names to keep JWTs compact: iss (issuer — who created the token), sub (subject — who the token is about, typically a user ID), aud (audience — who the token is intended for), exp (expiration time, Unix timestamp), nbf (not before, Unix timestamp), iat (issued at, Unix timestamp), and jti (JWT ID, a unique identifier for the token). Private claims are application-specific fields like roles, permissions, email, or user metadata.
The Payload is Base64URL-encoded, not encrypted. Any party who possesses the JWT can decode and read all claims without needing any key. Do not put sensitive information (passwords, PII beyond what is necessary) in a JWT payload unless you are using JWE (JSON Web Encryption) rather than JWS (JSON Web Signature). In most authentication systems, the JWT payload is considered readable by the client, and this is by design — the client needs to know expiry time, user roles, etc.
Decoding a JWT is not the same as verifying it. A decoded payload tells you what the token claims, but without verifying the signature against the issuing server's key, you cannot trust those claims. An attacker who intercepts or crafts a token can set any claims they want. The 'alg: none' attack involves sending a token with the algorithm set to 'none' and no signature — a naive verifier that does not validate the algorithm might accept it. Always verify against an explicit list of allowed algorithms.
Common JWT-related security issues to be aware of: JWT tokens with long expiration times create a revocation problem — once issued, a signed JWT is valid until it expires, and there is no standard way to invalidate it without maintaining a server-side blocklist. The HS256 algorithm uses a shared symmetric key, which means both signing and verification require the same secret — this is problematic in multi-service architectures. RS256 and ES256 use asymmetric key pairs (private key to sign, public key to verify), which allows any service to verify tokens without access to the signing key. For new systems, RS256 or ES256 is generally preferable to HS256.