Free JWT Decoder — Decode JSON Web Tokens Online

If you have ever debugged a "401 Unauthorized" error, dealt with expired sessions, or wondered why your API suddenly rejects authenticated requests — the answer is usually in the JWT. JSON Web Tokens are the backbone of modern authentication. Nearly every web application and API built in the last decade uses them.

Our free JWT decoder lets you paste any JWT and instantly see its decoded header, payload, and claims in a readable format. It shows expiration times in human-readable dates, highlights expired tokens, and formats the JSON for easy reading. Everything runs in your browser — your tokens never leave your device. This matters because JWTs often contain user IDs, permissions, and other sensitive data.

What Is a JWT and Why Should You Care?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token that carries information between two parties. It was standardized in RFC 7519 and has become the dominant token format for web authentication.

Before JWTs, most web applications used server-side sessions. The server stored session data in memory or a database, and the client held a session ID cookie. This worked but scaled poorly — every request required a database lookup, and load-balanced servers needed shared session storage.

JWTs solve this by putting the session data in the token itself. The server creates a token containing the user's ID, permissions, and expiration time, signs it with a secret key, and sends it to the client. On subsequent requests, the client sends the token back, and the server verifies the signature without needing to look anything up. The information is right there in the token.

This is why jwt.io (Auth0's decoder) is one of the most visited developer tools on the internet — developers constantly need to inspect tokens during development and debugging.

Anatomy of a JWT — Header, Payload, Signature

Every JWT has three parts separated by dots: xxxxx.yyyyy.zzzzz

Header

The header is a JSON object that specifies the token type and signing algorithm. It is Base64url encoded (not encrypted). A typical header:

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

alg is the signing algorithm (HS256, RS256, ES256, etc.). typ is always "JWT." Some headers include a kid (key ID) that tells the server which key was used to sign the token — useful when keys are rotated.

Payload

The payload contains the claims — the actual data the token carries. It is also Base64url encoded. A typical payload:

{"sub": "1234567890", "name": "John Doe", "iat": 1516239022, "exp": 1516242622}

Claims are key-value pairs. Some are registered (standardized), some are public (commonly used), and some are private (application-specific).

Signature

The signature verifies that the token has not been tampered with. It is created by taking the encoded header, the encoded payload, a secret key, and the algorithm specified in the header, then computing a cryptographic hash. Only someone with the secret key can create a valid signature.

Critical point: the signature does not encrypt the token. It only proves authenticity and integrity. Anyone can read the header and payload — they are just Base64 encoded.

Common JWT Claims Explained

These are the registered claims defined in the JWT specification. Not all are required, but you will see them constantly:

Claim	Full Name	Purpose	Example
iss	Issuer	Who created the token	"auth.example.com"
sub	Subject	Who the token is about (usually user ID)	"user_12345"
aud	Audience	Who the token is intended for	"api.example.com"
exp	Expiration	Unix timestamp when token expires	1711756800
iat	Issued At	Unix timestamp when token was created	1711670400
nbf	Not Before	Token is invalid before this time	1711670400
jti	JWT ID	Unique identifier for the token	"abc-123-xyz"

Our decoder automatically converts exp, iat, and nbf from Unix timestamps to human-readable dates so you can immediately see when a token was issued and when it expires without manually converting epoch seconds.

Sell Custom Apparel — We Handle Printing & Free Shipping

JWTs Are NOT Encrypted — Why This Matters

This is the most commonly misunderstood aspect of JWTs, and getting it wrong has serious security consequences.

Standard JWTs (technically JWS — JSON Web Signature) are signed, not encrypted. The header and payload are Base64url encoded, which is trivially reversible. Our decoder proves this — paste any JWT and you can read every claim. No key required.

This means:

• Never put passwords in a JWT. Anyone with the token can read them.
• Never put sensitive personal data in a JWT unless you are also encrypting the transport (HTTPS).
• Be careful with client-side storage. JWTs stored in localStorage are accessible to any JavaScript on the page. An XSS attack can steal the token and read all the claims.
• Minimize payload data. Include only what the server needs — user ID, role, expiration. Fetch additional user details from your database when needed.

There is a separate standard called JWE (JSON Web Encryption) that encrypts the payload. But it is rarely used in practice because HTTPS already encrypts data in transit, and most applications do not put sensitive data in token payloads.

Debugging JWT Issues — A Practical Guide

When authentication breaks, the JWT is usually the first place to look. Here are the most common issues and how to diagnose them:

401 Unauthorized — Token Expired

Decode the token and check the exp claim. Compare it to the current Unix timestamp. If exp is in the past, the token is expired. Solutions: implement token refresh logic, extend the token lifetime on the server, or detect expiration client-side and redirect to login before the API call.

401 Unauthorized — Invalid Signature

The server cannot verify the token's signature. Common causes: the signing key was rotated and the old key no longer works, the token was issued by a different service, or the token was tampered with (even adding a space breaks the signature).

403 Forbidden — Missing Permissions

The token is valid but lacks the required role or scope. Decode the payload and check the role, scope, or permissions claims. The user may need to be assigned additional permissions in your identity provider.

Token Not Accepted — Clock Skew

If your server's clock is slightly off from the issuer's clock, tokens might be rejected because they appear to be "not yet valid" (nbf) or "already expired" (exp). Most JWT libraries accept a few seconds of clock skew — configure this tolerance in your verification settings.

JWT Security Best Practices

1. Always validate the signature server-side. Never trust a JWT without verifying its signature. Client-side decoding is for debugging — never for access control.
2. Set short expiration times. Access tokens should expire in 5-15 minutes. Use refresh tokens (stored securely, ideally HTTP-only cookies) for longer sessions.
3. Use HTTPS exclusively. JWTs in transit on HTTP are readable by anyone on the network.
4. Store tokens securely. HTTP-only cookies are safer than localStorage because they are inaccessible to JavaScript and therefore immune to XSS theft.
5. Validate all claims. Check iss, aud, exp, and nbf on every request. An expired token from the right issuer should still be rejected.
6. Never use "alg": "none". The JWT spec allows unsigned tokens with "alg": "none". This is a known attack vector — always reject tokens with no algorithm.

HS256 vs RS256 — Choosing the Right Algorithm

The two most common JWT signing algorithms serve different architectures:

Property	HS256 (Symmetric)	RS256 (Asymmetric)
Key type	Shared secret	Public/private key pair
Who can sign?	Anyone with the secret	Only the private key holder
Who can verify?	Anyone with the secret	Anyone with the public key
Best for	Single server apps	Microservices, third-party auth
Key distribution	Must be kept secret	Public key can be shared openly
Performance	Faster	Slower (RSA math is expensive)

Use HS256 when the same server both creates and verifies tokens. Simple, fast, one key to manage.

Use RS256 when tokens need to be verified by services that should not have signing authority. Auth0, Firebase, and most identity providers use RS256 because they publish their public keys (via JWKS endpoints) so any service can verify tokens without having the signing key.

Frequently Asked Questions

What is a JWT token?

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and information exchange. It consists of three parts separated by dots: a header (algorithm and token type), a payload (claims/data), and a signature (verification). JWTs are used by most modern web applications and APIs for user authentication.

Are JWTs encrypted?

No. Standard JWTs (JWS) are signed but NOT encrypted. The header and payload are Base64url encoded, which means anyone can decode and read them. The signature only verifies that the token has not been tampered with — it does not hide the contents. Never put sensitive data like passwords in a JWT payload.

What do the common JWT claims mean?

"iss" is the issuer (who created the token), "sub" is the subject (who the token is about, usually a user ID), "aud" is the audience (who the token is intended for), "exp" is expiration (Unix timestamp when the token expires), "iat" is issued at (when the token was created), and "nbf" is not before (token is not valid before this time).

Is it safe to paste my JWT token into an online decoder?

It depends on the tool. Our decoder runs entirely in your browser — your token never leaves your device. Tools like jwt.io also decode client-side. However, some lesser-known tools may send your token to their server. Always verify that the tool processes locally, especially for production tokens.

Why does my JWT keep expiring?

JWTs have an expiration claim ("exp") set by the server. Common expiration times are 15 minutes for access tokens and 7-30 days for refresh tokens. If your token expires too quickly, the server's token lifetime configuration needs to be adjusted. Decode the token to check the "exp" claim and compare it to the current Unix timestamp.

What is the difference between HS256 and RS256?

HS256 (HMAC with SHA-256) uses a shared secret key — the same key signs and verifies the token. RS256 (RSA with SHA-256) uses a public/private key pair — a private key signs and a public key verifies. RS256 is preferred for distributed systems because the verification key can be shared publicly without compromising the signing key.