Decode and inspect any JSON Web Token (JWT) — view the header, payload and signature in a readable format. No server needed. Enter your secret to verify the signature locally.
Paste your full JWT string (the three base64url-encoded parts separated by dots) into the input box. The token is decoded client-side instantly — it is never sent to any server.
The decoder splits the token into its three parts: the Header (algorithm and token type), the Payload (claims including user data, expiry, and issuer), and the Signature. All values are shown in formatted JSON.
The tool automatically checks whether the token has expired based on the exp claim. Enter your secret key (HMAC) or public key (RSA/ECDSA) to verify the signature locally without any server-side call.
JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs consist of three Base64URL-encoded parts separated by dots: the Header (algorithm used), the Payload (claims — the actual data), and the Signature (proof of authenticity). JWTs are used for authentication, API authorisation, and information exchange.
This tool decodes JWTs entirely in your browser — no data is ever sent to any server. However, treat your JWT tokens like passwords: avoid pasting live production tokens into any online tool. For development and debugging, this tool is safe. For extra security, you can redact or replace the signature portion before pasting since the header and payload are not secret.
The Header contains the token type (JWT) and the signing algorithm (e.g. HS256, RS256). The Payload contains claims — standard claims include iss (issuer), sub (subject/user ID), exp (expiration time), iat (issued at), and nbf (not before), plus any custom claims your application adds. The Signature is a cryptographic hash of the header and payload, signed with a secret (HMAC) or private key (RSA/ECDSA).
HS256 (HMAC SHA-256) uses a shared secret key for both signing and verification — the same key is used by both the issuer and the verifier. RS256 (RSA SHA-256) uses asymmetric key pairs: the issuer signs with a private key, and verifiers check with the corresponding public key. RS256 allows public verification without exposing the signing key, making it better for multi-party systems. ES256 uses elliptic curve cryptography for smaller signatures.
The exp (expiration) claim in a JWT contains a Unix timestamp after which the token is no longer valid. Servers should reject any token where the current time exceeds exp. This tool calculates the current time against exp and displays whether the token is still valid, expired, or how much time remains. Token lifetimes vary from minutes (access tokens) to days or weeks (refresh tokens).
The payload of a JWT is Base64URL-encoded but not encrypted — anyone can read it. However, the signature makes tampering detectable: if you modify any part of the header or payload, the signature will no longer match and the server will reject the token. JWT does NOT prevent someone from reading the payload; it only prevents undetected modification. Use JWE (JSON Web Encryption) if you need to encrypt the payload.
Key vulnerabilities include: the "alg: none" attack (accepting tokens with no signature — always validate the algorithm), HMAC/RSA confusion (using a public RSA key as an HMAC secret), weak secrets (short HMAC secrets that can be brute-forced), missing expiry validation (never checking the exp claim), storing sensitive data in the payload (it's readable by anyone), and JWT injection in headers. Always validate algorithm, expiry, issuer, and audience.
