JWT Decoder Online — Free Tool + Tutorial

If you work with web authentication, you have almost certainly encountered a JSON Web Token (JWT). They are everywhere — in HTTP Authorization headers, OAuth responses, session cookies, and API keys. But what exactly is inside a JWT, and how can you read it? This guide explains JWTs from the ground up and introduces a free tool to decode them instantly.

What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure.

In simpler terms: a JWT is a way to securely transmit information between parties as a JSON object. It is digitally signed, so the information can be verified and trusted.

The JWT Structure

Every JWT consists of three parts, separated by dots:

xxxxx.yyyyy.zzzzz
^     ^     ^
|     |     |
Header  |     Signature
        |
       Payload

1. Header

The header typically consists of two parts: the type of token (JWT) and the signing algorithm being used (HMAC SHA256, RSA, etc.).

{
  "alg": "HS256",
  "typ": "JWT"
}

This JSON is then Base64Url encoded to form the first part of the JWT.

2. Payload

The payload contains the claims — statements about an entity (typically the user) and additional data. There are three types of claims:

• Registered claims: Predefined claims like iss (issuer), exp (expiration time), sub (subject), and aud (audience).
• Public claims: Custom claims defined by the community (e.g., https://yourdomain.com/claims/role).
• Private claims: Custom claims agreed upon by parties using the JWT (e.g., user_id, role, permissions).

{
  "sub": "1234567890",
  "name": "Jane Developer",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1516242622
}

Important: the payload is Base64 encoded, not encrypted. Anyone who intercepts a JWT can read its payload. Never put sensitive data (passwords, SSNs, credit card numbers) in a JWT.

3. Signature

The signature is created by taking the encoded header, the encoded payload, a secret key, and the algorithm specified in the header, then signing that combination.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

The signature verifies that the sender of the JWT is who it says it is and ensures the message was not altered in transit.

How to Decode a JWT Online

Our free JWT Decoder lets you paste any JWT and see its contents decoded and formatted — all running client-side in your browser. Here is why that matters:

Security-First Decoding

Many online JWT decoders send your token to a server for processing. This is a security risk because JWTs often contain sensitive information like user IDs, roles, and session data. When you use our decoder:

• All processing happens in your browser — your token never leaves your machine
• No network requests — the decoder uses pure JavaScript running locally
• No data storage — nothing is logged, cached, or transmitted

What the Decoder Shows

When you paste a JWT into the tool, you will see:

• Header decoded: Algorithm type and token type displayed as formatted JSON
• Payload decoded: All claims displayed with readable timestamps
• Expiry check: Whether the token is expired, when it was issued, and how long until it expires
• Signature verification: Visual confirmation of the signature algorithm

Common JWT Debugging Scenarios

Scenario 1: Token Expired Errors

The most common JWT error. Paste your token into the decoder and check the exp claim. If the timestamp is in the past, your token has expired. The solution is to implement a refresh token flow on the server side.

Scenario 2: Missing Claims

If your application expects a role or user_id claim but it is missing from the decoded payload, the issue is on the token generation side. Check your authentication server configuration.

Scenario 3: Signature Validation Failures

If a token is valid but the signature does not match, the signing key may have changed. The decoder shows the algorithm used — verify it matches what your server expects.

JWT Security Best Practices

Practice	Why
Never store secrets in the payload	Payload is Base64 encoded, not encrypted. Anyone can read it.
Always set an expiration (exp)	Tokens without expiry are valid forever if compromised.
Use HTTPS everywhere	Tokens in transit over HTTP can be intercepted.
Validate the issuer (iss)	Prevents token substitution attacks from other services.
Validate the audience (aud)	Ensures the token was intended for your service specifically.
Use strong signing keys	Weak keys can be brute-forced. Use at least 256-bit keys for HMAC.
Consider short-lived access tokens	5-15 minute access tokens with refresh tokens limit exposure window.

JWT vs. Session Tokens

Should you use JWTs or server-side sessions? Here is a quick comparison:

• JWTs are stateless — the server does not need to store session data. This makes them ideal for microservices and distributed systems. But they cannot be revoked easily (until expiry).
• Session tokens are stateful — the server stores session data. They can be revoked instantly but require server-side storage and do not scale as well across services.

For most applications, JWTs are the better choice when you have multiple services or need cross-origin authentication. Sessions are simpler for single-server applications.

Try the Free JWT Decoder

Ready to inspect your tokens? Our free JWT Decoder runs entirely in your browser — no data is sent to any server, no signup required, and it works instantly.

Decode a JWT Now →