Tools
Blog Home

Free Online JWT Decoder

Decode and inspect JSON Web Tokens directly in your browser. View the header, payload, and claims with readable expiration dates. Nothing is ever sent to a server.

Token Inspector

Algorithm
—
Type
—
Expiration
—

Header

Payload

Signature

Signature verification requires the secret key and is not supported in this tool.
All decoding happens locally in your browser. Your token is never uploaded, stored, or logged.

What is a JWT?

A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe way to represent claims between two parties. It is made of three Base64URL-encoded parts joined by dots — header.payload.signature. Its most common use is stateless authentication for REST APIs: after login, the server issues a signed token that the client sends with each request, so the server can verify identity without keeping session state.

JWT Structure: Header, Payload, Signature

Header

Declares the signing algorithm (alg, e.g. HS256, RS256, ES256) and the token type (typ), almost always JWT.

Payload

Carries the standard and custom claims. It is only Base64URL-encoded, not encrypted — anyone can read it, so never store secrets here.

Signature

Computed by signing the encoded header and payload with a secret or private key. It proves integrity but cannot be verified without that key.

Common JWT Claims Explained

The payload contains claims — statements about the token. These registered claims are defined by the JWT standard:

sub Subject — the principal the token is about, usually the user ID.
iss Issuer — identifies who issued the token.
aud Audience — the recipients the token is intended for.
exp Expiration Time — Unix timestamp after which the token must be rejected.
iat Issued At — Unix timestamp of when the token was created.
nbf Not Before — Unix timestamp before which the token must not be accepted.
jti JWT ID — a unique identifier, useful to prevent token replay.

JWT Security Best Practices

Never put sensitive data in the payload — it is only encoded, not encrypted, and is readable by anyone.
Always set an exp claim and keep token lifetimes short to limit the impact of a leaked token.
Prefer asymmetric algorithms (RS256 or ES256) for microservices so services can verify without sharing a secret.
Always validate the iss and aud claims server-side, and reject tokens whose alg is set to none.
Never expose tokens in URLs or log files; send them in the Authorization header and store them safely.

Frequently Asked Questions

No. A standard JWT is signed, not encrypted. The header and payload are only Base64URL-encoded, which means anyone who has the token can decode and read its contents. The signature only guarantees that the token has not been tampered with — it does not hide the data. If you need confidentiality, use JWE (JSON Web Encryption) or never place sensitive data in the payload.

No. Verifying a JWT signature requires the secret key (for HS256) or the public key (for RS256/ES256), which only the issuing server should hold. This tool intentionally decodes the token client-side without verification so that no key ever leaves your machine. Always verify signatures on your server, never in the browser.

HS256 is symmetric: the same secret key signs and verifies the token, so every party that can verify can also forge tokens. RS256 is asymmetric: a private key signs and a separate public key verifies. RS256 is preferred for distributed systems and microservices because you can share the public key freely while keeping the private signing key secret.

The exp claim is a Unix timestamp in seconds. A common bug is providing it in milliseconds (13 digits) instead of seconds (10 digits), which places the expiry far in the past or future. Clock skew between servers can also cause premature expiry — allow a small leeway when validating. Use the Token Inspector above to see the human-readable expiration date next to the raw value.