JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. JWTs are widely used in modern web applications to implement stateless authentication and secure information exchange between clients and servers. Because a JWT is self-contained, the server does not need to store session data in a database — all necessary information travels inside the token itself.

JWT became an open standard defined in RFC 7519 and is now foundational to OAuth 2.0 authorization flows, OpenID Connect identity layers, and countless REST API authentication schemes. You will encounter JWTs in virtually every technology stack, from Node.js microservices to mobile apps, single-page applications, and serverless functions.

The key benefit of a JWT over a traditional opaque session token is transparency with integrity. Any party in possession of the token can read the header and payload without a secret key, but they cannot forge or alter the token without invalidating the cryptographic signature. This makes JWTs particularly well-suited for stateless, distributed architectures where the server that issues a token might be different from the server that later validates it.

Common real-world uses of JWTs include:

• Authentication: After a user logs in, the server issues a JWT. Subsequent requests include the JWT so the server can identify the user without a session lookup.
• Authorization: JWTs carry role or permission claims that downstream services can check without contacting a central auth server.
• Information exchange: Signed JWTs let parties exchange verified data over insecure channels.
• Single sign-on (SSO): A single JWT can authenticate a user across multiple independent domains or services.

Every JWT consists of exactly three Base64URL-encoded parts separated by dots (.), giving it the familiar three-segment appearance you see when you paste a token into a JWT decoder. The three parts are the header, the payload, and the signature.

Header

The header is a JSON object that describes the token's metadata. It almost always contains two fields: alg, which names the signing algorithm (for example HS256, RS256, or ES256), and typ, which is set to the literal string JWT. The header JSON is then Base64URL-encoded to produce the first segment of the token. Common algorithms include HMAC-SHA256 (symmetric, shared secret), RSA-SHA256 (asymmetric, public/private key pair), and ECDSA P-256 (elliptic-curve variant of RSA).

Payload

The payload is a JSON object containing the claims — statements about the subject and any additional metadata. The JWT specification defines several registered claim names that carry standardized meanings:

• sub (subject): Identifies the principal that is the subject of the JWT, typically a user ID.
• iss (issuer): Identifies the party that issued the token.
• aud (audience): Identifies the recipients for whom the token is intended.
• iat (issued at): Unix timestamp (seconds since epoch) when the token was issued.
• exp (expiration time): Unix timestamp after which the token must not be accepted.
• nbf (not before): Unix timestamp before which the token must not be accepted.
• jti (JWT ID): A unique identifier for the token to prevent replay attacks.

In addition to registered claims, applications freely add public and private claims such as name, email, role, or any application-specific field.

Signature

The signature is computed by taking the encoded header, a dot, and the encoded payload, then signing that string with the algorithm and secret specified in the header. For HS256, the operation is HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). The result is Base64URL-encoded and appended as the third segment. Any modification to the header or payload will produce a different signature, immediately revealing tampering.

This free online JWT decoder takes a token string, splits it on the . character, and processes each of the three resulting segments. The decoder performs a pure client-side Base64URL decode of the header and payload — no data is ever sent to any server, making this tool safe to use with real tokens in a development or debugging context.

The Base64URL decoding process used by the tool follows these exact steps:

1. Replace every - character with + and every _ character with / to convert Base64URL encoding back to standard Base64.
2. Pad the resulting string with = characters until its length is a multiple of 4, because standard Base64 requires this.
3. Call the browser's built-in atob() function to decode the Base64 string to a binary string.
4. Percent-encode each character as a two-digit hex sequence, then pass the result through decodeURIComponent() to correctly handle multi-byte UTF-8 characters, including emoji and accented letters.
5. Parse the resulting string as JSON to produce the header or payload object.

After decoding, the tool extracts well-known timestamp claims from the payload. For the exp (expiration) claim, it multiplies the Unix epoch seconds value by 1000 to obtain a JavaScript-compatible millisecond timestamp, then compares it to new Date() to determine whether the token is currently valid or has expired. The same millisecond conversion applies to iat (issued at) and nbf (not before) for human-readable display. The signature segment is displayed as-is because verifying it requires the secret key or public key — information the decoder intentionally does not request.

The tool provides instant, real-time decoding as you type or paste tokens. If the token does not contain exactly three dot-separated segments, an error message is shown immediately. This makes the JWT decoder ideal for rapid debugging of authentication issues, inspecting tokens returned by identity providers, and confirming that claims like sub, role, or email carry the expected values.

Understanding what a JWT decoder can and cannot do is critical for anyone working with token-based authentication. A JWT decoder reads and displays the header and payload, but it does not verify the signature. This distinction has major security implications that developers must keep in mind.

Because the header and payload are only Base64URL-encoded — not encrypted — anyone who intercepts a JWT can decode it and read its claims. This means JWTs are not confidential by default. Never store sensitive data such as passwords, credit card numbers, or personally identifiable information in a JWT payload unless you are also using JSON Web Encryption (JWE) to encrypt the entire token.

The security of a JWT rests entirely on the signature. A server-side JWT validation library will:

• Re-compute the expected signature from the received header and payload using the known secret or public key.
• Compare that expected signature to the signature segment in constant time to prevent timing attacks.
• Reject the token if the signatures do not match — this would indicate tampering or a forged token.
• Check the exp claim to ensure the token has not expired.
• Optionally check iss, aud, and nbf claims for additional validation.

A particularly dangerous mistake is accepting the algorithm specified in the token's own header without whitelisting allowed algorithms on the server. Early JWT libraries had a vulnerability where an attacker could set alg: "none" in the header, causing some libraries to skip signature verification entirely. Always configure your JWT library to accept only the specific algorithm(s) your system uses.

When using this decoder tool, treat decoded payloads as informational only. Never make authorization decisions based solely on a client-side decoded JWT — always perform full server-side signature verification using a trusted library before granting access to protected resources.

The JWT specification defines a compact vocabulary of registered claim names that carry standardized meanings across all implementations. Understanding these claims helps you inspect tokens efficiently and debug authentication issues quickly. The table below summarizes the most frequently encountered claims, their data types, and how this decoder tool presents them.

Beyond registered claims, applications routinely add custom claims such as role, email, name, permissions, and tenant_id. These appear in the payload alongside the standard claims and are displayed in full by this decoder. When debugging access control issues, checking these custom claims is often the first step to understanding why a user is or is not authorized for a particular resource.

JWT-based authentication and traditional server-side session tokens represent two fundamentally different philosophies for managing user identity. Choosing the right approach for your application requires understanding the trade-offs each brings.

Traditional session tokens are opaque random strings stored in a server-side session store (a database, Redis cache, or memory). When a request arrives, the server looks up the token in the store to retrieve user data. This approach is simple, supports instant revocation (just delete the session record), and keeps sensitive data on the server. The drawback is that it introduces a centralized store that must be shared across all server instances in a distributed deployment, adding latency and a single point of failure.

JWTs are self-contained. All user information travels in the token, so any server can validate a request without a database call — only the cryptographic verification is needed. This makes JWTs excellent for microservices, multi-region deployments, and API gateways. However, JWTs cannot be revoked before their expiration time without maintaining a blocklist, which reintroduces shared state. Short expiration windows (15 minutes to 1 hour) combined with refresh token rotation are the standard mitigation.

Use JWTs when you need stateless, horizontally scalable authentication, when multiple independent services share an identity provider, or when you need to pass verifiable claims across trust boundaries. Prefer server-side sessions when you need instant revocation, when all traffic passes through a single application tier, or when compliance requirements prohibit storing user attributes in a client-readable format.