JWT Decoder

What Is a JSON Web Token (JWT)?

A JSON Web Token, commonly abbreviated as JWT (pronounced “jot”), is a compact, URL-safe token format defined by RFC 7519. JWTs are the de facto standard for transmitting authentication and authorization claims between a client and a server in modern web applications. When you log into a single-page app or call a protected API, the server typically issues a JWT that your client stores and sends with every subsequent request. Because a JWT is cryptographically signed, the server can verify its authenticity without querying a database or session store on every request.

JWTs are widely adopted across OAuth 2.0, OpenID Connect, and countless microservice architectures. Unlike opaque session tokens, a JWT is self-contained: the token itself carries all the information the server needs to authenticate and authorize the user. This makes JWTs especially popular in distributed systems where multiple services need to verify identity without sharing a centralized session database.

JWT Structure: Header, Payload, and Signature

Every JWT consists of three Base64URL-encoded parts separated by dots:

header.payload.signature

1. Header

The header is a JSON object that describes the token type and the signing algorithm. A typical header looks like this:

{
  "alg": "HS256",
  "typ": "JWT"
}

The alg field specifies the algorithm used to sign the token, such as HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), or ES256 (ECDSA with SHA-256). The typ field is almost always "JWT". Some tokens include a kid (Key ID) field to help the server select the correct verification key from a set of keys.

2. Payload (Claims)

The payload contains the claims — statements about the user and metadata. Claims fall into three categories:

• Registered claims are standard fields defined by the spec:iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID).
• Public claims are custom claims registered in the IANA JSON Web Token Claims registry to avoid collisions, such as email or name.
• Private claims are application-specific claims agreed upon by the producer and consumer, such as role, permissions, or tenant_id.

The exp claim is especially important — it sets the token's expiration as a Unix timestamp. Our decoder automatically checks this claim and shows whether the token is still valid or has expired. The iat (issued at) and nbf (not before) timestamps are displayed in human-readable format so you can quickly understand the token's time window.

3. Signature

The signature is created by taking the encoded header, a dot, the encoded payload, and signing them with the specified algorithm and a secret key (for HMAC) or a private key (for RSA/ECDSA). For example, with HS256:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

The signature ensures that the token has not been tampered with. If a single character in the header or payload is changed, the signature verification will fail. Note that this decoder displays the signature as a hex string — to verify a signature you need the signing key, which is not required for simple decoding.

Common JWT Claims Explained

JWT vs. Session Tokens

Traditional session-based authentication stores a session ID in a cookie. The server maintains a session store (in memory, Redis, or a database) and looks up the session on every request. This approach works well for monolithic applications but introduces challenges in distributed systems: every service needs access to the shared session store, creating a single point of failure.

JWTs solve this by embedding all necessary information directly in the token. Any service with the signing key (or the public key for asymmetric algorithms) can independently verify the token without a network call. This stateless model scales naturally across microservices and serverless functions. However, the trade-off is that JWTs cannot be easily revoked before their expiration — once issued, a JWT remains valid until it expires. To mitigate this, applications typically use short-lived access tokens combined with refresh tokens.

JWT Security Considerations

• Do not store secrets in the payload. The payload is Base64URL-encoded, not encrypted. Anyone with the token can decode and read the payload. Never include passwords, API keys, or other sensitive data in a JWT.
• Always validate the signature. Decoding a JWT (what this tool does) is not the same as verifying it. Your backend must verify the signature using the correct key before trusting any claims.
• Use strong algorithms. Prefer RS256 or ES256 over HS256 for production systems, especially when multiple services need to verify tokens. Asymmetric algorithms let you distribute a public key without exposing the signing secret.
• Set short expiration times. Keep access token lifetimes short (5 to 15 minutes) to minimize the window of exposure if a token is leaked. Use refresh tokens to obtain new access tokens without requiring the user to re-authenticate.
• Beware the “none” algorithm attack. Some JWT libraries historically accepted tokens with alg: "none", effectively bypassing signature verification. Always reject tokens with unexpected algorithms.
• Store tokens securely on the client. For browser applications, use httpOnly cookies rather than localStorage to prevent XSS attacks from accessing tokens.

Frequently Asked Questions

Is it safe to paste my JWT into this tool?

Yes. This decoder runs entirely in your browser using JavaScript. Your token is never transmitted to any server. You can verify this by opening your browser's Network tab and confirming that no requests are made when you paste a token.

Can this tool verify a JWT signature?

No. This tool decodes the JWT and displays its contents, but it does not verify the cryptographic signature. Signature verification requires the signing secret (for HMAC) or the public key (for RSA/ECDSA), which should never be shared with a client-side tool.

Why is my JWT showing as expired?

The decoder reads the exp claim from the payload and compares it to your device's current time. If the current time is past the expiration timestamp, the token is marked as expired. Make sure your system clock is accurate. In production, expired tokens should be refreshed using a refresh token.

What is the difference between decoding and verifying a JWT?

Decoding simply means Base64URL-decoding the header and payload to read their JSON content. Anyone can do this — no secret is needed. Verifying means recomputing the signature using the algorithm and key, then comparing it to the token's signature. Only a party with the correct key can verify a JWT. Your backend should always verify before trusting any claims.

Can a JWT be encrypted?

Yes. JWE (JSON Web Encryption, RFC 7516) provides encrypted tokens where the payload is not readable without the decryption key. However, most applications use JWS (JSON Web Signature) tokens, which are signed but not encrypted. The tokens you typically encounter in Authorization headers are JWS tokens that this decoder can read.