JWT Decoder

JWTs are everywhere in modern web authentication. OAuth flows, API authorization headers, session tokens, single sign-on implementations, and inter-service authentication in microservice architectures all commonly use them. Which means debugging authentication issues, inspecting what claims a token contains, checking whether a token has expired, or verifying that a token was issued by the right source are tasks that come up regularly for anyone working with web applications.

The token itself is not encrypted. It is Base64-encoded. Any JWT can be decoded and read by anyone who has it, which is a frequently misunderstood point about how JWTs work and why storing sensitive data in them is a mistake. This tool decodes the structure and presents the contents in a readable format without requiring any libraries, any server calls, or any context about the signing key.

What a JWT Actually Is

A JSON Web Token is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded sections separated by dots: the header, the payload, and the signature. A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNzE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three sections. Three dots. Each one independently decodable.

The header contains metadata about the token itself. At minimum it specifies the algorithm used to sign the token (alg) and the token type (typ, which is always JWT). Common algorithm values include HS256 for HMAC-SHA256, RS256 for RSA with SHA-256, and ES256 for ECDSA with SHA-256. The algorithm declared in the header matters because it determines how the signature is verified and because certain algorithm confusion attacks exploit implementations that accept whatever algorithm the token claims to use.

The payload contains the claims, which are statements about an entity (typically the authenticated user) and any additional metadata the issuer chose to include. Claims come in three categories. Registered claims are standardized names defined in the RFC: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Public claims are names registered in the IANA JSON Web Token Claims registry to avoid collisions. Private claims are custom claims agreed upon between the parties using the token, commonly things like user roles, permissions, tenant identifiers, or application-specific user attributes.

The signature is produced by taking the encoded header and payload, joining them with a dot, and running the result through the algorithm specified in the header with the signing key. The signature cannot be decoded back to a key. It can only be verified by recomputing it with the correct key and checking whether the result matches. This means a JWT decoder can show you the header and payload contents without any knowledge of the signing key. Verifying the signature is a different operation from decoding the content.

What This Tool Shows You

Paste any JWT into the tool and it decodes all three sections immediately. The header and payload are parsed and displayed as formatted JSON so the claims are readable rather than presented as a raw Base64 string. The expiration status is evaluated against the current time, so you can see at a glance whether the token is currently valid, expired, or not yet active based on its exp and nbf claims if present.

Here is how to use it:

1. Paste your JWT into the input field. The token can be pasted with or without the Bearer prefix that typically precedes it in Authorization headers.
2. The header, payload, and signature sections are decoded and displayed immediately.
3. Review the claims in the payload: who issued the token, what subject it represents, what permissions or roles it carries, and when it expires.
4. Check the expiration analysis to see whether the token is currently active, expired, or has a not-before time that has not yet been reached.
5. Copy any section of the decoded output to your clipboard.

The tool processes the token entirely in your browser. The JWT is never sent to any server. This matters because tokens frequently contain user identity information, session data, and authorization claims that you would rather not transmit to a third-party service.

Decoding Is Not Verifying

This distinction is important enough to state clearly rather than assume. Decoding a JWT shows you its contents. Verifying a JWT confirms that those contents can be trusted.

Anyone can create a JWT with any claims they want, sign it with any key they choose, and hand it to your decoder. The decoder will show you the claims. It cannot tell you whether those claims are legitimate. Verification requires checking the signature against the public key or shared secret of the issuer you trust, and it is a server-side operation that your application performs, not something a browser-based decoder tool does.

This is also why the alg: none attack is a real concern in poorly implemented JWT libraries. A token with the algorithm set to none and no signature can be constructed to claim any identity, and a library that blindly trusts the algorithm declared in the header will accept it. Auditing the alg field in the decoded header, which this tool shows clearly, is one reason developers use decoders during security review.

Standard JWT Claims and What They Mean

The registered claims are worth knowing by name because they appear in almost every JWT and their presence or absence affects how a token should be handled.

iss (issuer) identifies who created and signed the token. Your application should reject tokens with an issuer it does not recognize. In a multi-tenant environment, this claim distinguishes tokens from different authorization servers.

sub (subject) identifies the principal the token represents, typically a user ID. This is the value your application uses to look up the user or entity the token belongs to.

aud (audience) identifies the recipients the token is intended for. Your application should reject tokens where the audience does not include itself, because a token issued for service A should not be accepted by service B.

exp (expiration time) is a Unix timestamp after which the token must not be accepted. This is the claim the expiration check in this tool evaluates. A token with an exp in the past is expired and should be rejected by any compliant implementation.

nbf (not before) is a Unix timestamp before which the token must not be accepted. Less commonly used than exp but relevant for tokens issued in advance of a valid period.

iat (issued at) is a Unix timestamp recording when the token was issued. Useful for auditing and for implementing additional age-based validation beyond the exp claim.

jti (JWT ID) is a unique identifier for the token that can be used to prevent replay attacks by maintaining a list of used token IDs for the token's valid lifetime.

Debugging Authentication Flows With JWT Decoding

JWT decoding is a practical debugging technique rather than just an inspection exercise. When an authentication flow is behaving unexpectedly, the decoded token is frequently where the answer is.

Common things the decoded payload reveals during debugging: the subject claim does not match the user you expected, meaning the token was issued for a different identity than the one that should be authenticated. The expiration timestamp has already passed, causing the server to reject the token with a 401 that is not obviously explained by the client-side error message. The audience claim does not include the service receiving the token, which compliant implementations reject. A role or permission claim is missing or has an unexpected value, which explains why an authorization check is failing. The issuer is an unexpected value, which can happen when a staging token is being presented to a production service or vice versa.

For API development workflows where you are working with JWT-authenticated endpoints alongside other request manipulation, the decoded token gives you visibility into what the server sees when it processes the Authorization header. Combined with tools that let you inspect and format the JSON responses from those endpoints, the JSON Formatter being the obvious companion here, the debugging loop becomes considerably faster.

For the cryptographic operations that sit alongside JWT authentication in a security stack, the HMAC Generator covers the HMAC signing operations that HS256-signed JWTs rely on, and the Argon2 Hash Generator handles password hashing for the user authentication layer that sits before token issuance.

Security Considerations When Using JWTs

A few things about JWT security that are relevant to understanding what this decoder shows and what it cannot tell you.

Do not store sensitive data in JWT payloads. The payload is encoded, not encrypted. Anyone with the token can read it. User IDs, roles, and non-sensitive session identifiers belong in a JWT. Passwords, full payment information, government identification numbers, and private keys do not.

Short expiration times reduce the window of opportunity if a token is stolen. A token that expires in 15 minutes is much less useful to an attacker than one that expires in 30 days. The exp claim the decoder shows you directly reflects this design decision.

The signing algorithm matters. none should never be accepted. Symmetric algorithms like HS256 use a shared secret, meaning any party that can verify tokens can also issue them. Asymmetric algorithms like RS256 use a private key to sign and a public key to verify, so verification can be distributed without sharing the ability to issue tokens. The alg field in the header decoded by this tool is one of the first things to check during a security audit of a JWT implementation.

Frequently Asked Questions

Can I verify a JWT signature with this tool?

No. This tool decodes the header and payload contents and evaluates expiration timing. Signature verification requires the signing key, which is a secret held by the issuer and is not something a client-side decoder should ever have access to. Signature verification is performed server-side by your application using the issuer's public key or shared secret.

Is it safe to paste a JWT into this tool?

The tool processes everything client-side in your browser. Your token is not transmitted to any server. That said, JWTs represent authentication state and should be treated with the same care as any credential. Avoid pasting production tokens from live user sessions into any tool unnecessarily, and rotate tokens that may have been exposed.

Why can I read the JWT payload without a key?

JWT payloads are Base64URL-encoded, not encrypted. The encoding makes them URL-safe and compact but provides no confidentiality. The signing key is used to produce and verify the signature, which proves the token was issued by a trusted party and has not been tampered with. It does not hide the claims from anyone who reads the token.

What does it mean when a JWT has no expiration claim?

A JWT without an exp claim does not expire by time. Whether to accept non-expiring tokens is a policy decision for your application. In most security contexts, non-expiring tokens are a risk because a compromised token remains valid indefinitely. Applications that issue non-expiring tokens typically implement revocation through a token blocklist or by storing token IDs server-side.

What is the difference between HS256 and RS256?

Both are signing algorithms used in JWTs. HS256 (HMAC-SHA256) uses a shared symmetric secret that must be known to both the issuer and any party verifying tokens. RS256 (RSA-SHA256) uses an asymmetric key pair: the issuer signs with a private key and verifiers check the signature using the corresponding public key. RS256 allows token verification to be distributed without distributing the ability to issue tokens.