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.

Last updated: 2026-09-20

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.

What this JWT decoder does

A JWT (JSON Web Token) is three parts — header, payload and signature — joined by dots. It looks encrypted at a glance, but **the header and payload are merely Base64URL-encoded, not encrypted.** Anyone can read them. Paste a token here and this tool shows the header and payload as formatted JSON and tells you whether the expiry claim has passed.

**It does not verify the signature.** That is deliberate: verifying would mean asking you to paste a secret or public key into this page, and inviting anyone to paste keys into a web page is not something worth encouraging. So the fact that this tool can read a token is no guarantee that the token is legitimate. Treat it as an inspection and debugging aid. Decoding happens entirely in your browser and the token you paste is never transmitted.

How to inspect a JWT

Paste the token Enter the string in its usual `xxxxx.yyyyy.zzzzz` form.
Read the header It gives the signing algorithm (alg) and the token type (typ). Whether alg says `none` is worth a look.
Read the payload Claims such as the issuer (iss), the subject (sub) and the expiry (exp) appear formatted.
Check the expiry verdict If exp lies in the past, the token is reported as expired.

Tips for getting more out of it

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.

Where this helps

Narrowing down an authentication failure

When a request returns 401, you can see for yourself whether the token has expired or the audience claim does not match.

Checking what the payload actually carries

After adding a claim in your own auth service, you can confirm immediately that it lands as intended.

Auditing for information that should not be there

**The payload is readable by anyone.** Use this to check that no email addresses, permission details or other sensitive values have crept in.

Reviewing token lifetimes

The gap between exp and iat tells you whether the real validity period matches what you designed.

JWT terms explained

Header: The part carrying the signing algorithm (alg) and token type (typ). It sits before the first dot.
Payload (claims): The information the token carries. **It is only Base64URL-encoded, not encrypted, so anyone can read it.**
Signature: The part that assures the header and payload have not been tampered with. Verifying it requires a key.
Base64URL: The variant defined in RFC 4648 that uses `-` and `_` in place of `+` and `/` and drops the trailing `=` padding, so the value survives being placed in a URL.
exp (expiry): The claim giving the moment the token stops being valid, as a Unix timestamp in seconds.
alg: none: A value meaning no signature. **An implementation that accepts this unconditionally lets anyone forge a token**, which is a well-known class of vulnerability.

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.

Browse all trivia