JWT Decoder & Verifier
Decode and verify JSON Web Tokens with signature validation, live expiry countdown, and claim explanations.
About JWT Decoder & Verifier
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined in RFC 7519 that enables the secure transmission of claims between two parties. A JWT consists of three Base64URL-encoded segments separated by dots: a header, a payload, and a signature. The header declares the token type and the signing algorithm (such as HS256, RS256, or ES256). The payload carries a set of claims -- key-value pairs that convey information like the user's identity, roles, token issuer, and expiration time. The signature is computed over the encoded header and payload using either a shared secret (HMAC) or a private key (RSA, ECDSA), allowing any party with the corresponding secret or public key to verify that the token has not been tampered with.
JWTs are the backbone of modern stateless authentication. In a traditional session-based architecture, the server stores session state and issues a session ID cookie; every request requires a server-side lookup. With JWTs, the token itself contains all the information the server needs to authenticate and authorize a request, eliminating the need for centralized session storage. This property makes JWTs particularly well-suited to distributed systems, microservice architectures, and single-page applications where requests may be handled by any node in a cluster. The server signs the token at login and trusts the signature on subsequent requests, verifying it cryptographically rather than querying a database.
However, JWTs are not without pitfalls. Because the payload is only Base64URL-encoded and not encrypted, anyone who intercepts a JWT can read its contents -- so sensitive data should never be placed in the payload unless the token is also encrypted (becoming a JWE). Tokens must be transmitted over HTTPS, stored securely (HttpOnly cookies are preferred over localStorage to mitigate XSS attacks), and given short expiration times to limit the window of abuse if a token is leaked. Developers also need to validate claims rigorously on the server side: checking the 'exp' (expiration), 'iss' (issuer), 'aud' (audience), and 'nbf' (not before) claims prevents expired, forged, or misrouted tokens from being accepted. A JWT decoder is an essential diagnostic tool for inspecting these claims during development and debugging.
How to Use the JWT Decoder
- Paste a complete JWT string into the input field. The token should consist of three Base64URL-encoded segments separated by two dots (e.g., eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature).
- The tool automatically decodes the header and payload sections, displaying the raw JSON for each. Examine the header to confirm the algorithm (alg) and token type (typ).
- Review the decoded payload to inspect claims such as 'sub' (subject/user ID), 'iss' (issuer), 'aud' (audience), 'exp' (expiration timestamp), 'iat' (issued at), and any custom claims your application includes.
- Check the expiration status -- the tool converts the 'exp' Unix timestamp to a human-readable date and indicates whether the token is currently valid or expired.
- If signature verification is supported, enter the HMAC secret or paste the RSA/ECDSA public key to verify that the token's signature is valid and that the payload has not been modified since signing.
- Use the structured output to debug authentication issues: mismatched audience claims, expired tokens, incorrect algorithm configurations, and missing required claims are among the most common JWT-related bugs.
Common Use Cases
Debugging Authentication Failures
When a user reports being unexpectedly logged out or receiving 401 errors, the first diagnostic step is to decode the JWT from the request headers. By inspecting the 'exp' claim, developers can determine whether the token has expired. Examining the 'iss' and 'aud' claims reveals whether the token was issued by the correct identity provider and intended for the correct service, catching misconfiguration issues that are invisible from error messages alone.
Verifying Token Claims in Microservice Architectures
In a microservice system, a JWT issued by the API gateway travels through multiple downstream services. Each service may require specific claims -- a billing service checks the 'subscription_tier' claim, while an admin service validates the 'roles' array. Decoding the token at each stage allows developers to verify that the required claims are present, correctly formatted, and propagated without loss or corruption across service boundaries.
Security Auditing and Penetration Testing
Security engineers decode JWTs to audit what information is exposed in the payload. Tokens that contain personally identifiable information (PII), internal database IDs, or permission escalation paths represent security risks. Decoding also reveals the signing algorithm, allowing auditors to flag weak algorithms like 'none' (no signature) or HS256 used where RS256 would be more appropriate for the threat model.
API Integration and Third-Party Token Inspection
When integrating with third-party OAuth2 providers (Google, Auth0, Okta), developers receive ID tokens and access tokens as JWTs. Decoding these tokens during integration helps verify that the expected scopes, claims, and audience values are present, significantly reducing the trial-and-error cycle of configuring OAuth2 flows correctly.
Frequently Asked Questions
Is it safe to decode a JWT in the browser?
Decoding the header and payload is perfectly safe because these sections are not encrypted -- they are merely Base64URL-encoded. Anyone who has the token can decode these parts. The security of a JWT lies in its signature, which prevents modification, not in the secrecy of its contents. However, you should never paste production tokens containing sensitive data into untrusted third-party websites. A client-side decoder that processes the token entirely in your browser without sending it to a server is the safest option.
What is the difference between HS256, RS256, and ES256?
HS256 (HMAC-SHA256) is a symmetric algorithm where the same secret key is used to both sign and verify the token. RS256 (RSA-SHA256) is asymmetric: a private key signs the token and a public key verifies it, making it ideal for systems where the verifier should not be able to create tokens. ES256 (ECDSA-SHA256) is also asymmetric but uses elliptic curve cryptography, producing smaller signatures and requiring less computational power than RSA while providing equivalent security. Most production systems prefer RS256 or ES256 for their security properties.
Why does my JWT have three parts separated by dots?
The three dot-separated parts correspond to the header, payload, and signature. The header specifies the signing algorithm and token type. The payload contains the claims (the actual data). The signature is computed by applying the specified algorithm to the Base64URL-encoded header and payload, ensuring that any modification to either section invalidates the signature. This three-part structure is defined by RFC 7519 and is fundamental to how JWTs provide integrity protection.
What happens if a JWT expires?
When a JWT's 'exp' (expiration) claim timestamp is in the past, any server that properly validates tokens will reject it with a 401 Unauthorized response. The client must then obtain a new token, typically by using a refresh token to request a fresh access token from the authorization server without requiring the user to log in again. Short expiration times (15 minutes to 1 hour for access tokens) limit the damage if a token is stolen, while longer-lived refresh tokens (days to weeks) maintain a convenient user experience.
Can I modify a JWT's payload and still use it?
No. If you modify any part of the payload, the signature will no longer match, and any server that verifies signatures will reject the token. The signature is computed over the exact bytes of the encoded header and payload, so even a single changed character invalidates it. This is the fundamental security property of JWTs -- they are tamper-evident. The only way to create a valid modified token is to re-sign it with the correct secret or private key.
What is the difference between a JWT and a JWE?
A JWT (specifically a JWS -- JSON Web Signature) provides integrity and authenticity: you can verify who created the token and that it has not been modified, but anyone can read the payload. A JWE (JSON Web Encryption) provides confidentiality: the payload is encrypted so that only authorized parties with the decryption key can read it. When you need both integrity and confidentiality, you can nest a JWS inside a JWE. Use JWEs when the token payload contains sensitive information that must not be exposed to intermediaries or client-side code.