JSON Web Tokens (JWTs) are a compact, URL-safe means of representing claims to be transferred between two parties. They're widely used in modern web applications for authentication, authorization, and information exchange. Our JWT Decoder helps you inspect and understand the contents of these tokens by decoding and displaying their header and payload in a readable format.
This tool performs all decoding locally in your browser. JWTs you paste are never sent to any server, making it safe to decode tokens containing sensitive information. However, it's important to understand that this tool only decodes tokens—it does not verify their signatures. Decoding a token doesn't prove it's valid or trustworthy.
Understanding JWT Structure
A JWT consists of three parts separated by dots: the header, the payload, and the signature. Each part is base64url encoded, creating the familiar format: xxxxx.yyyyy.zzzzz.
Header: Contains metadata about the token, typically the algorithm used for signing (alg) and the token type (typ). For example: {"alg": "RS256", "typ": "JWT"}. The algorithm field tells systems how to verify the signature.
Payload: Contains the claims—statements about an entity (typically the user) and additional data. Claims are categorized as registered (standard names like "exp" for expiration), public (defined in IANA registry), or private (custom claims agreed upon by parties using the token).
Signature: Created by combining the encoded header and payload with a secret key using the algorithm specified in the header. The signature ensures that the token hasn't been altered. Without the secret key, you can decode a token but cannot verify its authenticity or create valid tokens.
Common JWT Claims
iss (Issuer): Identifies who issued the token. This might be a URL or identifier of your authentication server.
sub (Subject): Identifies the subject of the token, typically a user ID or email address.
aud (Audience): Identifies the intended recipients of the token. Servers should reject tokens not intended for them.
exp (Expiration Time): The timestamp after which the token should be rejected. Expressed as seconds since Unix epoch.
iat (Issued At): When the token was created. Useful for determining token age.
nbf (Not Before): The token should not be accepted before this time. Useful for tokens that become valid in the future.
jti (JWT ID): A unique identifier for the token. Can be used to prevent token replay attacks.
Security Considerations
JWTs are not encrypted by default—they're only encoded. Anyone who intercepts a JWT can decode and read its contents. Never include sensitive data like passwords in JWT payloads unless you're using encrypted JWTs (JWE).
The signature prevents tampering but doesn't hide data. An attacker can't modify a signed JWT without invalidating the signature, but they can read everything in it. Treat JWTs like you would any other credential—transmit over HTTPS and don't log their contents.
Token expiration is critical. Short-lived tokens limit the damage if a token is compromised. Most applications use access tokens that expire in minutes or hours, with refresh tokens to obtain new access tokens without re-authentication.
This Tool's Limitations
Our decoder displays the token's contents but does not verify signatures. Signature verification requires access to the secret key (for HMAC algorithms) or public key (for RSA/ECDSA), which this browser-based tool doesn't have.
A decoded token tells you what claims it contains, but only signature verification confirms those claims are authentic. For debugging and development, decoding is often sufficient. For production validation, always verify signatures on your server.
Why Use a JWT Decoder?
During development, decoding JWTs helps debug authentication issues by showing exactly what claims are included. You can verify expiration times, check claim values, and understand what information your tokens carry.
For learning and understanding OAuth/OpenID Connect flows, decoding tokens helps visualize what information is being exchanged. When integrating with third-party authentication providers, decoding their tokens reveals what claims they include.
Common Use Cases
Debugging Authentication Issues
Decode JWTs to inspect claims, verify expiration times, and understand why authentication might be failing.
Understanding Third-Party Tokens
Decode tokens from OAuth providers or third-party services to see what claims and data they include.
Verifying Token Contents
Confirm that JWTs contain the expected claims before integrating with authentication systems.
Learning JWT Structure
Understand how JWTs work by decoding example tokens and seeing their header, payload, and signature structure.
Token Expiration Analysis
Check when tokens expire and how long they remain valid by examining exp and iat claims.
API Development
During API development, decode tokens to ensure your application generates tokens with correct claims.
Worked Examples
Decoding a Standard JWT
Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Output
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}This example JWT contains a simple payload with a subject (user ID), name, and issued-at timestamp. The HS256 algorithm indicates the signature uses HMAC with SHA-256.
Expired Token Detection
Input
A JWT with exp: 1609459200 (Jan 1, 2021)
Output
Status: EXPIRED Expired: January 1, 2021 12:00:00 AM
The decoder automatically checks the exp claim against the current time and indicates whether the token has expired.
Frequently Asked Questions
Does this tool verify JWT signatures?
No. This tool only decodes JWTs to display their contents. Signature verification requires the secret key (for HMAC) or public key (for RSA/ECDSA), which we don't have access to. For production validation, always verify signatures on your server.
Is it safe to paste my JWT here?
Yes, for inspection purposes. All decoding happens locally in your browser—the token is never sent to any server. However, never share JWTs in insecure channels as they can contain sensitive information and may grant access to resources.
What does "Token Expired" mean?
It means the current time is past the exp (expiration) claim in the token. Expired tokens should be rejected by servers. The token may have been valid when issued but is no longer accepted.
Can I use this decoded information to forge a token?
No. While you can see the token contents, you cannot create a valid signature without the secret key. Any modification to the header or payload would require a new signature, which only the key holder can create.
What are the timestamps in the payload?
JWT timestamps (exp, iat, nbf) are expressed as Unix time—seconds since January 1, 1970 UTC. Our decoder automatically converts these to human-readable dates and times in your local timezone.
Why does my JWT look like random characters?
JWTs are base64url encoded, which transforms the JSON data into a URL-safe string. The decoder reverses this encoding to show the original JSON content. The "random" appearance is by design for safe transmission.