What Is a JSON Web Token (JWT)?
A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties as a JSON object. JWTs are defined in RFC 7519 and consist of three parts separated by dots: a header, a payload, and a signature. The header and payload are Base64url-encoded JSON objects, while the signature ensures the token has not been tampered with. JWTs are widely used in authentication, authorization, and information exchange across modern web applications, single-page applications, mobile apps, and microservices architectures.
How Does JWT Decoding Work?
JWT decoding is the process of extracting the readable information from a token without verifying its cryptographic signature. A JWT consists of three Base64url-encoded parts separated by periods: header.payload.signature. Decoding involves splitting the token at the dots, then applying Base64url decoding to the first two parts to reveal the JSON content. Base64url encoding differs from standard Base64 by replacing + with -, / with _, and removing padding = characters. This tool decodes the header and payload sections, presenting them as formatted, human-readable JSON.
Understanding the JWT Header
The JWT header typically contains metadata about the token itself. The most common fields are alg (the signing algorithm such as HS256, RS256, or ES256) and typ (the token type, usually "JWT"). Some headers also include kid (key ID) to identify which cryptographic key was used to sign the token, or jku (JWK Set URL) pointing to the public key set. Understanding the header helps developers verify they are using the correct algorithm and key for token validation.
Understanding the JWT Payload
The JWT payload contains claims — statements about the user or entity and additional metadata. Standard registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Beyond these, applications add custom claims like user roles, permissions, email addresses, or any application-specific data. The payload is not encrypted by default — it is merely encoded — so sensitive data should not be stored in a JWT without additional encryption (JWE).
Token Expiry and Time-Based Claims
One of the most important claims in a JWT is the exp (expiration) claim, which specifies when the token becomes invalid. This value is a Unix timestamp (seconds since January 1, 1970 UTC). This decoder automatically detects the exp claim and displays it as a human-readable date and time, along with whether the token has already expired. Other time-based claims include iat (when the token was issued) and nbf (the earliest time the token is valid). These claims help enforce token lifecycle management and prevent replay attacks.
How to Use This JWT Decoder
To decode a JWT, paste the complete token string into the input textarea and click "Decode JWT." The tool splits the token into its three components, Base64url-decodes the header and payload, and displays them as formatted JSON with proper indentation. If the payload contains an exp claim, the tool also shows the expiration date in a human-readable format and indicates whether the token is currently expired. Everything runs locally in your browser — no token data is sent to any server.
JWT Security Considerations
While this tool decodes JWTs, it does not verify signatures. Decoding reveals the token contents but does not confirm authenticity or integrity. In production systems, always verify the signature using the appropriate secret or public key before trusting token claims. Never store sensitive information in JWT payloads without additional encryption, as anyone with the token can decode and read the payload. Use short expiration times, rotate signing keys regularly, and implement token revocation mechanisms for robust security.
Common JWT Use Cases
JWTs are used extensively in modern application architectures. OAuth 2.0 and OpenID Connect use JWTs as access tokens and ID tokens. Single sign-on (SSO) systems pass user identity across services using JWTs. API gateways validate JWTs to authorize requests without querying a central database. Microservices propagate user context via JWTs in request headers. Stateless session management replaces server-side sessions with client-held JWTs, reducing server memory usage and enabling horizontal scaling.
Privacy and Client-Side Processing
This JWT decoder operates entirely within your web browser using JavaScript. Your token is never transmitted to any server, logged, or stored. This makes it safe to decode tokens containing sensitive claims, user information, or authentication data. The tool is ideal for debugging authentication flows, inspecting token contents during development, or verifying that tokens contain the expected claims before deploying to production.
Frequently Asked Questions
Can this tool verify JWT signatures?
No. This tool only decodes the header and payload sections of a JWT. Signature verification requires the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms). This decoder is intended for inspecting token contents, not for validating authenticity. For production signature verification, use a server-side JWT library appropriate for your programming language.
Is it safe to paste my JWT token here?
Yes. This tool runs entirely in your browser — no data is sent to any server. Your token never leaves your device. However, be aware that JWTs are sensitive credentials. Avoid sharing tokens in public channels, and use short-lived tokens with proper expiration times in production systems.
What does the expiry time show?
If the decoded payload contains an exp claim, the tool converts the Unix timestamp to a human-readable date and time in your local timezone. It also indicates whether the token has already expired or is still valid. This helps developers quickly check token validity during debugging.
Why does my JWT fail to decode?
JWT decoding can fail if the token is malformed, truncated, or not a valid JWT format. A valid JWT must have exactly three parts separated by dots. Ensure you have copied the complete token without any extra whitespace, line breaks, or missing characters. Some systems add a "Bearer " prefix — remove that before pasting.
What is the difference between Base64 and Base64url encoding?
Base64url is a URL-safe variant of Base64 encoding. It replaces + with - and / with _, and omits the padding = characters. This makes the encoded string safe for use in URLs, HTTP headers, and file names without requiring additional percent-encoding. JWTs use Base64url encoding for their header and payload sections.