Free JWT Decoder

With session-based authentication, the server stores session data in a database or memory store (like Redis) and sends the client a session ID cookie. Every request requires the server to look up the session. With JWT authentication, all the session data is encoded inside the token itself, so the server only needs to verify the signature, no database lookup required. This makes JWTs ideal for stateless, horizontally-scaled APIs and microservice architectures where sharing a session store across servers is impractical. The tradeoff is that JWTs cannot be individually revoked without maintaining a blocklist, whereas session cookies can be invalidated instantly by deleting the server-side session.

API keys are static, opaque strings that act as simple credentials, the server must look up each key in a database to determine what access it grants. JWTs are self-contained tokens that carry their own claims (user identity, permissions, expiration) and are cryptographically signed, so the server can verify them without a database call. API keys typically do not expire unless manually rotated, creating a security risk if leaked. JWTs have built-in expiration (the "exp" claim), limiting the window of exposure. In practice, many systems use both: an API key to identify the application, and a JWT to authenticate the individual user within that application.

No. Signature verification requires the secret key (for HS256) or the public key (for RS256, ES256, or EdDSA) that corresponds to the key used to sign the token. Since this tool runs entirely in your browser and does not connect to any key server, it cannot verify signatures. It decodes and displays the header, payload, and raw signature bytes. To verify a signature, you would need the signing key and a library like jsonwebtoken (Node.js), PyJWT (Python), or the jose library (JavaScript). Services like Auth0 and Firebase publish their public keys at well-known JWKS endpoints for this purpose.

JWS (JSON Web Signature, RFC 7515) is a signed token, the payload is Base64url-encoded and readable by anyone, but the signature proves it has not been tampered with. This is what most people mean when they say "JWT," and it is what this tool decodes. JWE (JSON Web Encryption, RFC 7516) is an encrypted token, the payload is encrypted so that only the intended recipient with the decryption key can read it. JWE tokens have five dot-separated parts instead of three. If your token has five parts, it is a JWE and cannot be decoded by this tool without the decryption key. In practice, JWS is far more common; JWE is used when the token payload itself must be confidential in transit.

Yes. This tool decodes any standard JWT regardless of the issuer. Auth0 issues JWTs signed with RS256 by default and includes claims like "azp" (authorized party) and custom namespaced claims. Firebase Authentication tokens use RS256 and include "firebase" as a custom claim with sign-in provider details. AWS Cognito issues both access tokens and ID tokens as JWTs with claims like "cognito:groups" and "token_use." Okta tokens include "scp" (scopes) and "cid" (client ID). Paste any of these into the decoder and you will see every claim the provider embedded in the token.

The "exp" (expiration time) claim is a Unix timestamp (seconds since January 1, 1970 UTC) that specifies when the token becomes invalid. This decoder reads the "exp" value, converts it to a human-readable date, and compares it to your device's current time to show whether the token is still valid or has expired. Short-lived tokens (5-15 minutes) are a security best practice because they limit the damage if a token is leaked. Refresh tokens or silent re-authentication are used to obtain new access tokens without forcing the user to log in again. If your token has no "exp" claim, it never expires, which is generally considered a security risk.

JWTs became popular with the rise of single-page applications (SPAs), mobile apps, and microservice architectures. In these environments, maintaining a centralized session store becomes a bottleneck and a single point of failure. JWTs are self-contained, any server with the signing key can verify them independently, enabling horizontal scaling without shared state. They also work well across domains (unlike cookies, which are bound to a single domain), making them ideal for APIs consumed by web apps, mobile apps, and third-party integrations simultaneously. The OAuth 2.0 and OpenID Connect specifications standardized JWTs as the token format, cementing their role in modern authentication.

There is no hard limit in the JWT specification itself, but practical limits exist. Most web servers and browsers impose header size limits, Nginx defaults to 8KB for all headers combined, Apache defaults to 8KB per header, and AWS API Gateway limits headers to 10KB. Since JWTs are typically sent in the Authorization header, a token exceeding a few kilobytes can cause "431 Request Header Fields Too Large" errors. In practice, a well-designed JWT should be under 2KB. If your tokens are growing large, consider moving bulky claims (like detailed permissions) to an API endpoint and keeping only essential claims (sub, exp, iss, roles) in the token.

Yes, it is 100% free with no usage limits, no signup, and no per-decode charges. Many developer tools charge for premium features or limit free usage, but because this decoder runs entirely in your browser with no backend, there are no server costs to pass on. Use it as many times as you need for debugging, development, or learning.

Yes. When you decode a token, the tool reads the "exp" (expiration time) and "iat" (issued at) claims from the payload, converts the Unix timestamps to human-readable dates in your local timezone, and displays whether the token is currently valid or expired. This is one of the most common reasons developers decode JWTs, to quickly check whether an authentication failure is caused by an expired token before diving into server logs or code.

If the input is not a valid JWT (not three dot-separated Base64url-encoded segments), the tool will show an error indicating the token could not be decoded. Common causes of malformed tokens include accidentally copying extra whitespace, truncating the token when pasting from a terminal, or pasting a JWE (five-part encrypted token) instead of a JWS (three-part signed token). Make sure you copy the complete token string including all three parts separated by dots.