JWT Decoder
Decode JSON Web Tokens to inspect header, payload, and signature. Shows expiry status and human-readable dates.
How to Use This Tool
- 1
Paste your JWT (the three-part dot-separated string) into the input field.
- 2
The decoder will split and display the header and payload as formatted JSON.
- 3
Check the expiry section to see whether the token is still valid, already expired, or has no expiry.
- 4
Human-readable timestamps for iat (issued at), exp (expiry), and nbf (not before) are shown automatically.
What is JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519 that is widely used for authentication and information exchange between parties. A JWT consists of three Base64URL-encoded sections separated by dots: a header that describes the token type and signing algorithm, a payload that contains claims (statements about a user or system), and a signature used to verify the token has not been tampered with.
JWTs are stateless — the server does not need to look up a session in a database to authenticate a request. Instead, it verifies the signature using a secret or public key, trusts the payload if the signature is valid, and uses claims like sub (subject/user ID), exp (expiry timestamp), iss (issuer), and aud (audience) to make authorization decisions. This makes JWTs popular in microservice architectures and single-page applications that communicate with APIs.
Decoding a JWT is not the same as verifying one. Our decoder shows you what's inside the header and payload — the algorithm used, the user ID, roles, expiry time — without requiring the signing secret. This is useful for debugging: checking whether a token has expired, confirming the correct claims are present, or understanding what an API is returning. Signature verification requires the secret and belongs in your application's authentication layer, not a browser tool.
Frequently Asked Questions
helpIs decoding a JWT the same as verifying it?
No. Decoding only reads the Base64URL-encoded header and payload — anyone can do this without the signing secret. Verification checks the cryptographic signature to confirm the token was issued by a trusted party and has not been modified. Never trust a decoded JWT's claims without verifying the signature in your application.
helpIs my token sent to a server?
No. Decoding is done entirely in your browser using JavaScript. Your JWT is never transmitted to any server. Even so, avoid pasting production tokens containing sensitive user data into any online tool — use test tokens or redacted examples instead.
helpWhat are the most common JWT claims?
Standard claims defined in RFC 7519 include: sub (subject — typically a user ID), iss (issuer — who created the token), aud (audience — who the token is intended for), exp (expiration time), iat (issued at), and nbf (not before). Applications often add private claims for roles, permissions, and other user attributes.
helpWhy does my JWT have three parts separated by dots?
The three parts are the header, payload, and signature — each independently Base64URL-encoded. The header describes the token type (JWT) and signing algorithm (e.g., HS256 or RS256). The payload holds claims. The signature is a cryptographic hash of the first two parts, produced using a secret key to prevent tampering.