JWT Decoder

Paste a JWT (JSON Web Token) to instantly decode its header and payload, including an expiration (exp) check. No signature verification is performed and no secret key is required.

Common Registered Claims

Claim Name Description
iss Issuer A string or URL identifying the principal that issued the token.
sub Subject The subject the token refers to (typically a user ID).
aud Audience The intended recipient(s) or API for which the token is meant.
exp Expiration Time The time (Unix seconds) after which the token must no longer be accepted.
nbf Not Before The time (Unix seconds) before which the token must not be accepted.
iat Issued At The time (Unix seconds) at which the token was issued.
jti JWT ID A unique identifier for the token, often used to detect replay attacks.

Tips

  • The JWT you paste in is processed entirely by JavaScript in your browser and is never sent to toolbase.cc's servers, so any personal or credential data inside the token stays private.
  • A JWT is a Base64URL string made of three parts — header, payload, and signature — separated by periods. The header and payload are plain text that anyone can decode (Base64 is encoding, not encryption), so never put secrets like passwords into the payload.
  • If an API request fails with a 401 error because a token has expired, checking the exp claim with this tool is usually the fastest way to confirm the cause.
  • You can check the signing algorithm in the alg header. Implementations that accept alg: none are vulnerable to the well-known JWT "alg=none" attack, so servers must always restrict the set of allowed algorithms explicitly.

Frequently Asked Questions

Yes. The header and payload of a JWT are Base64URL-encoded, not encrypted, so anyone can read their contents. Sensitive information such as passwords or credit card numbers should never be placed in the payload.

No, this tool only decodes and displays the header and payload — it does not verify the signature. Verifying a signature requires a secret key (or an RSA/EC public key) known only to the token issuer, and entering that key into a browser tool would itself be a security risk.

Most APIs and authentication servers reject a JWT whose exp claim is earlier than the current time, typically returning a 401 Unauthorized error. In that case the client needs to obtain a new token, for example by using a refresh token.
ツールくん

Side Note — How JWTs Make "Stateless Authentication" Possible

JWT (JSON Web Token) was standardized by the IETF as RFC 7519 in 2015. Traditional session-based authentication required the server to keep a lookup table mapping session IDs to user data, but JWT instead embeds the user information directly inside the token and uses a signature to detect tampering. This lets a server verify authentication state without maintaining a session store — an approach known as "stateless authentication" — which is why JWTs are widely used for authentication across distributed systems and microservices spanning multiple servers.

A JWT is structured as three parts — "header.payload.signature" — each Base64URL-encoded and joined by periods. The crucial point is that the header and payload are merely encoded, not encrypted. Anyone can decode them and read the contents, so a JWT guarantees that the data has not been tampered with, not that its contents are kept secret. If you need to keep information confidential, you must use a separate specification called JWE (JSON Web Encryption), which adds actual encryption.

Signing schemes broadly fall into two categories: HMAC-based schemes (such as HS256), where the sender and receiver share the same secret key, and public-key schemes (such as RS256 and ES256), where a private key signs the token and a public key verifies it. Since JWT was adopted as the format for OAuth 2.0 and OpenID Connect access and ID tokens, it has become the de facto standard format for web authentication infrastructure.

More tools in this category