JWT Decoder
Decode and inspect JSON Web Tokens (JWT) directly in your browser. View header parameters, payload data claims, human-readable expiration dates, and signature components with zero server uploads.
How to use
Paste your encoded JWT string (header.payload.signature) into the input box, or click Try an example.
View the decoded Header JSON containing algorithm and token type metadata.
Inspect the Payload claims, including user identities, roles, and permissions.
Check the automatic token status badge to verify whether the token is currently active or expired.
Click Copy Payload or Download to export decoded claims for debugging.
Anatomy of a JSON Web Token (JWT)
A JSON Web Token (RFC 7519) is a compact, URL-safe container format commonly used for authentication and authorization in modern web architecture. A JWT consists of three distinct parts concatenated with periods (.):
- Header: Specifies the token type (typically
JWT) and the cryptographic signing algorithm (such asHS256,RS256, orES256). - Payload: Contains the claims—statements regarding an entity (often a user) and additional metadata such as permissions, email addresses, and tenant identifiers.
- Signature: A cryptographic hash created by combining the encoded header, encoded payload, and a secret key or private key. The signature guarantees that the token has not been altered in transit.
Standard registered JWT claims explained
The IANA JSON Web Token Claims registry specifies standard abbreviations for common security claims:
sub(Subject): The principal identity of the token (such as a unique user ID).iss(Issuer): The identity provider or authentication server that issued the token.aud(Audience): The intended recipients or API backend for which the token is valid.exp(Expiration Time): Unix timestamp indicating when the token ceases to be valid. Tokens must be rejected after this time.iat(Issued At): Unix timestamp recording when the authentication server minted the token.nbf(Not Before): Unix timestamp indicating the earliest moment the token is acceptable for processing.
Why signature verification must happen on your server
Decoding a token reveals what is written inside it, but decoding does not verify that the token is authentic. Anyone can create or modify an unsigned Base64URL string. Validating a token requires verifying its cryptographic signature against your API server's secret key (for HMAC) or public key (for RSA/ECDSA). Never paste private keys or production HMAC secrets into public web browsers. Proper signature validation belongs strictly in your backend authorization middleware.
Token security and privacy practices
JSON Web Tokens are Base64URL encoded, not encrypted. Any client that intercepts or stores a token can inspect its entire payload. For this reason, sensitive information such as database passwords, credit card details, or unhashed personal identification numbers should never be placed directly inside a JWT payload unless an encrypted token format (JWE / RFC 7516) is utilized.
Complete local privacy guarantee
Authentication tokens frequently contain user email addresses, internal corporate roles, and session IDs. Transmitting production tokens to third-party online decoders creates significant compliance and data leakage hazards. This tool parses and decodes your tokens entirely inside your local browser using client-side JavaScript. No tokens are sent over the network or logged on external servers.
Frequently asked questions
Does this tool send my JWT token to any server?
No. The entire decoding process takes place locally in your browser's JavaScript engine. Your token is never uploaded or logged anywhere.
Can this tool verify the signature of my token?
No. Signature verification requires your cryptographic secret key or private key. To protect your application security, you should never paste secret signing keys into an online browser tool. Verify signatures on your backend servers.
Why is my JWT payload readable if it is supposed to be secure?
JWTs are encoded using Base64URL, not encrypted. The signature prevents tampering, but the payload itself remains readable by any system handling the token. Use JWE (JSON Web Encryption) if the payload must remain confidential.
What do 'exp' and 'iat' mean?
'exp' is the expiration timestamp (in seconds since the Unix epoch), and 'iat' is the timestamp indicating when the token was issued. This tool automatically converts these numbers into readable dates and relative time.
What should I do if a token shows as expired?
Expired tokens cannot be accepted by APIs. You should refresh the token using an OAuth refresh token flow or request a new login session from your identity provider.