Back

JWT Decoder

JSON Web Tokens (JWTs) are a compact, URL-safe way to represent claims between two parties. Most JWTs are signed using JWS (JSON Web Signature), which ensures integrity but does not encrypt the contents. This tool decodes the header and payload to reveal claims, displays timestamps in human-readable format, and shows the token's expiration status.

Specifications

Common Use Cases

  • Debug OAuth 2.0 and OpenID Connect authentication flows
  • Inspect access tokens and ID tokens from identity providers (Auth0, Okta, Keycloak)
  • Verify token claims match expected values during API development
  • Check token expiration when troubleshooting "401 Unauthorized" errors
  • Understand token structure when integrating with third-party services
  • Audit tokens for security review (algorithm, claims, expiration)

Features

  • Decode JWT header and payload (JWS format)
  • Display algorithm (HS256, RS256, ES256, PS256, EdDSA) and token type
  • Parse registered claims: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID)
  • Show expiration status with human-readable countdown
  • Copy decoded sections as formatted JSON

Examples

OAuth 2.0 Access Token

Try it →

A typical access token with standard claims including subject, issuer, and expiration.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Tips

  • JWS tokens (the most common type) are signed but not encrypted. Anyone with the token can read the payload by Base64-decoding it.
  • JWE tokens encrypt the payload, but are less common. This tool decodes JWS tokens.
  • Always verify signatures server-side before trusting claims. This tool shows decoded content but does not verify signatures.
  • The "alg": "none" algorithm is a security risk and should be rejected by servers.
  • Symmetric algorithms (HS256) use a shared secret; asymmetric algorithms (RS256, ES256) use public/private key pairs.
  • The "exp" claim is a Unix timestamp in seconds. Check it to avoid accepting expired tokens.

Understanding JWT

JSON Web Tokens (JWTs) are the dominant token format for modern web authentication and authorization. A JWT is a compact, URL-safe string composed of three Base64url-encoded segments separated by dots: a header specifying the signing algorithm, a payload containing claims about the user or session, and a cryptographic signature that ensures the token has not been tampered with. This structure allows any party to read the token's contents by simple Base64 decoding, while only parties with the signing key can create or verify valid tokens.

Most JWTs use the JWS (JSON Web Signature) format, where the payload is signed but not encrypted. The header's "alg" field specifies the algorithm: symmetric algorithms like HS256 use a shared secret known to both issuer and verifier, while asymmetric algorithms like RS256 and ES256 use a private key for signing and a public key for verification. Asymmetric algorithms are preferred in distributed systems because the verification key can be shared publicly without compromising the signing key.

The payload contains registered claims defined by RFC 7519: "iss" (issuer), "sub" (subject), "aud" (audience), "exp" (expiration time), "nbf" (not before), "iat" (issued at), and "jti" (JWT ID). OAuth 2.0 and OpenID Connect layer additional claims for scopes, roles, and user profile information. The "exp" claim is critical for security — tokens without expiration or with excessively long lifetimes are a common vulnerability.

JWTs are used in OAuth 2.0 access tokens, OpenID Connect ID tokens, API authentication, and session management. Identity providers like Auth0, Okta, and Keycloak issue JWTs that applications verify without contacting the provider, enabling stateless authentication. However, this also means revocation is difficult — a compromised token remains valid until it expires, which is why short expiration times and token refresh flows are essential security practices.

Because JWS tokens are Base64url-encoded rather than encrypted, anyone who possesses the token can decode and read the header and payload. Sensitive information such as passwords, credit card numbers, and secrets should never be placed in a JWT payload. JWE (JSON Web Encryption) tokens do encrypt the payload, but they are far less common in practice. The distinction between encoding and encryption is one of the most important things to understand when working with JWTs.

The choice of signing algorithm has significant security implications. HS256 is a symmetric algorithm that uses a single shared secret for both signing and verification, making it simple to implement but requiring both parties to securely store the same secret. RS256 and ES256 are asymmetric algorithms that use a private key for signing and a public key for verification. In distributed systems, asymmetric algorithms are preferred because the public key can be shared openly — often through a JWKS (JSON Web Key Set) endpoint — without compromising the signing key. The "alg": "none" option signals an unsigned token with no signature at all, meaning anyone can forge tokens with arbitrary claims. A well-known attack involves changing the algorithm header to "none" and stripping the signature. Servers should always validate the algorithm against an allowlist and reject unsigned tokens.

Proper expiration handling is essential for JWT security. Applications should check the "exp" claim on every request before trusting the token. When a token expires, a refresh token (stored securely, often in an httpOnly cookie) can be used to obtain a new access token without requiring the user to log in again. Keeping access token lifetimes short — typically 5 to 15 minutes — limits the window of exposure if a token is compromised. Implementing token refresh proactively, before the access token actually expires, avoids user-facing interruptions in the application.

← Back to all tools