JWT Decoder
Decode and inspect JSON Web Tokens (JWT) instantly. View the header, payload, and signature claims. Check token expiration, issuer, audience, and other standard claims. All decoding happens locally in your browser for security.
How to Use This JWT Decoder
1. Paste your JWT token into the input field above. A valid JWT has three parts separated by dots (header.payload.signature).
2. Click "Decode JWT" or simply paste the token to see automatic decoding as you type.
3. View the decoded header showing the algorithm and token type, the payload containing all claims and data, and the signature.
4. Check the status indicator at the top to see if the token is valid, expired, or has no expiration claim.
5. Review the claims grid which displays important claims like expiration time, issuer, and subject in a readable format.
6. Use "Copy Payload" to copy the decoded payload JSON to your clipboard for use in other applications.
7. Try the sample tokens to see examples of basic and OAuth-style JWTs.
What is a JWT?
JSON Web Token (JWT, pronounced "jot") is an open standard defined in RFC 7519 for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs have become the dominant method for handling authentication and authorization in modern web applications, mobile apps, APIs, and microservices architectures.
A JWT consists of three parts separated by dots: the Header, Payload, and Signature. The header contains metadata about the token, including the signing algorithm used. The payload contains the claims, which are statements about the user and additional data. The signature is used to verify that the token has not been tampered with and, when using asymmetric algorithms, to verify the sender's identity.
Both the header and payload are Base64Url encoded, which means they can be easily decoded by anyone who has the token. This is important to understand: JWTs are not encrypted by default. The signature provides integrity verification but does not hide the contents. Sensitive data should never be stored in a JWT payload unless the token is also encrypted (known as JWE - JSON Web Encryption).
JWT Structure Explained
Header: Typically contains two properties: alg (the signing algorithm like HS256, RS256) and typ (the token type, usually "JWT"). Some tokens include a kid (key ID) when multiple signing keys are in use.
Payload: Contains the claims. Claims are statements about an entity (typically the user) and additional metadata. There are three types of claims: registered claims (predefined), public claims (defined in the IANA JSON Web Token Registry), and private claims (custom claims agreed upon by parties).
Signature: Created by taking the encoded header, encoded payload, a secret key, and the algorithm specified in the header. The signature ensures the token has not been altered after it was issued.
Common JWT Claims
iss(Issuer) - Identifies who issued the token, typically a URL or identifier of the authentication serversub(Subject) - The user or entity the token represents, often a user ID or emailaud(Audience) - The intended recipient of the token, ensuring tokens are not misused across different applicationsexp(Expiration) - When the token expires as a Unix timestamp; tokens should not be accepted after this timenbf(Not Before) - The time before which the token should not be acceptediat(Issued At) - When the token was created, useful for determining token agejti(JWT ID) - A unique identifier for the token, useful for preventing replay attacks
Security Considerations
This decoder only decodes the JWT to display its contents - it does not verify the signature. Signature verification requires the secret key (for HMAC algorithms) or public key (for RSA/ECDSA algorithms) used to sign the token. In production systems, always verify signatures before trusting any claims in a JWT.
All decoding in this tool happens locally in your browser using JavaScript. Your tokens are never transmitted to any server, ensuring complete privacy. However, be cautious when pasting production tokens into any online tool, as they may contain sensitive information or grant access to protected resources if still valid.
Best practices for JWT security include: using short expiration times, implementing token refresh mechanisms, validating all claims server-side, using strong signing keys, and considering token revocation strategies for sensitive applications.