JWT Decoder Online: What It Is and How to Use It

If you have ever worked on an app with user logins, you have almost certainly dealt with a JSON Web Token. They show up in API responses, Authorization headers, browser storage, and cookie jars. When something breaks and authentication stops working, the first instinct is to find a jwt decoder online and look inside the token. This guide explains exactly what you are looking at when you do that, and why it matters to use a decoder that keeps your token private.

What is a JWT and why do developers use them?

A JWT (pronounced 'jot') is a small, self-contained text string that an application uses to prove who you are and what you are allowed to do. Think of it like a signed visitor badge at a corporate office: the badge carries your name and your access level, and the security desk can check it without calling reception every time you walk through a door.

Before JWTs, most apps used sessions: when you logged in, the server stored a record of your login in a database and gave you a session ID. Every time you made a request, the server looked up that session ID in the database to confirm you were still logged in. That works fine for a single server. It becomes painful when you have ten servers, or when your API is running in a different place than your login service.

JWTs solve this by moving the information into the token itself. The server issues a token that contains your user ID, your permissions, and an expiry time, then signs the whole thing cryptographically. Any server that knows the signing key (or has the matching public key) can verify the token and trust its contents without touching a database. This is called stateless authentication, and it is why JWTs became the standard for APIs, mobile apps, and microservices.

The trade-off: a JWT is not encrypted by default. Anyone who gets hold of the token can read what is inside it. The signature only proves it has not been tampered with. This is why choosing a safe jwt decoder online matters more than most developers realise.

The three parts of a JWT: header, payload, signature

Every JWT looks like three blocks of scrambled text separated by dots. Here is a real example (this is a demonstration token with no real credentials):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MiIsIm5hbWUiOiJBbGljZSBNYXJ0aW4iLCJyb2xlIjoiZWRpdG9yIiwiaWF0IjoxNzUxMzI4MDAwLCJleHAiOjE3NTEzMzE2MDB9.k3Xm9QpT2vRnJwL8sYeHdFcBqA1ZoNtPmKuVxGiE4rU

Those three sections are the header, the payload, and the signature. Each one is Base64URL-encoded, which is a way of turning binary data into plain text that is safe to put in a URL. It is not encryption: any jwt decoder online can reverse it instantly. Here is what each section contains:

Part 1: The header

The header is the first block (everything before the first dot). Decoded, it looks like this:

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

It carries just two fields. The alg field names the algorithm used to create the signature: HS256 means the token was signed using a shared secret key. The typ field is always JWT. This section tells the receiving server how to verify the signature before trusting anything else in the token.

Part 2: The payload

The payload is the second block. This is the interesting part. Decoded, the example above gives you:

{
  "sub": "user_482",
  "name": "Alice Martin",
  "role": "editor",
  "iat": 1751328000,
  "exp": 1751331600
}

The fields in the payload are called claims. Some are standard (defined by the JWT specification), and some are custom (added by the application that issued the token). The standard claims you will see most often are:

• •sub (subject): the unique identifier for the user. Usually a database user ID.
• •iat (issued at): a Unix timestamp saying when the token was created. In the example above, that is a number representing a date and time in seconds.
• •exp (expiry): a Unix timestamp after which the token is no longer valid. The most common reason a token is rejected is that exp is in the past.
• •iss (issuer): the name of the server or service that issued the token. Used when multiple systems might send tokens to your API.
• •aud (audience): who the token is intended for. Your API should reject a token whose aud does not match its own identifier.
• •nbf (not before): the token is invalid before this timestamp.
• •jti (JWT ID): a unique ID for this specific token. Used to prevent the same token being used twice.

Custom claims like name and role in the example above are not part of the specification. Any application can add whatever fields it needs. A medical app might add department and clearance_level. An e-commerce platform might add subscription_tier and store_id.

Part 3: The signature

The signature is the third block. It is created by taking the encoded header, a dot, the encoded payload, running them through a cryptographic algorithm with a secret key, and encoding the result. It is the only part of a JWT that requires a key to produce or verify.

The signature does not hide the header or payload. Its job is to prove they have not been changed. If you alter even a single character in the payload (say, changing role from editor to admin), the signature will no longer match, and any server verifying the token will reject it. This tamper-proof property is the entire point of a JWT.

When to decode vs. when to verify

These two actions sound similar but they are completely different in terms of what they prove and when you should use each one.

Decoding is what a jwt decoder online does. You can read every claim in the payload without knowing the signing key. This is by design: the data is not supposed to be secret, only trustworthy. This is also why decoding alone is never enough for access control.

Verification is what your server does on every authenticated API request. It decodes the token, then uses the signing key to mathematically confirm the signature is valid, then checks that exp is in the future, then checks iss, aud, and any other claims your application cares about. If any check fails, the request is rejected.

The most common mistake developers make is calling their library's decode function instead of its verify function in production code. The decode function gives you the claims with no security checks. If you use it in an API route to check roles or permissions, you are accepting whatever the token claims without confirming it was legitimately issued. An attacker who intercepts a valid token can modify the payload and re-encode it with no signature, and your code will accept it.

How to use the AlteredIdea JWT Decoder: step by step

The AlteredIdea JWT Decoder is at alteredidea.com/tools/dev/jwt-decoder. Here is exactly what to do.

1. 1.Get the token. If you are debugging an API call, open your browser DevTools (F12 or right-click, Inspect), go to the Network tab, click the failing request, and look at the Request Headers. The token is the long string after 'Bearer ' in the Authorization header. Copy the entire token string, including all three dot-separated sections. If you are testing and do not have a real token, click the Demo button on the tool page to load a sample token.
2. 2.Paste it into the input field. The tool accepts the token immediately. You do not need to press a button or hit Enter. The decoded output appears as soon as you paste.
3. 3.Read the colour-coded preview. Just below the input, the token is split into three coloured segments: red for the header, purple for the payload, cyan for the signature. This makes it easy to see if the token is intact or has been truncated.
4. 4.Check the info bar. At the top of the decoded output you will see the algorithm (e.g. HS256), the token type (JWT), the issued-at time in human-readable format, and a green Valid or red Expired badge based on whether the exp timestamp is in the past.
5. 5.Read the payload claims table. The payload section shows every claim in a two-column table. Timestamps like exp, iat, and nbf are displayed as both the raw Unix number and a readable date and time in your local timezone.
6. 6.Confirm expiry. If the token shows Expired, the exp timestamp is in the past. Your application needs to issue a fresh token. If it shows Valid, expiry is not your problem: look at the iss, aud, or custom claims for a mismatch with what your server expects.

The tool does not verify the signature. Signature verification requires the secret key (for HS256) or the matching public key (for RS256 and ES256). Those keys should never leave your server. The decoder gives you everything you need to diagnose most JWT problems without ever touching the key.

Security warning: never paste production tokens into a tool that sends data to a server

This is the most important section of this article. A JWT is a credential. If it grants access to a user account or an API, it is functionally equivalent to a password for as long as it remains valid. Most developers understand not to share passwords, but many paste JWTs into online tools without thinking twice.

The most popular jwt decoder online, jwt.io, is owned by Auth0 (now part of Okta). It is a well-built and widely trusted tool. However, when you paste a token into jwt.io, that token is transmitted to their servers for decoding. If your token contains a user ID, email address, permissions, or any other sensitive claim, you have just sent that credential to a third party.

For a development token with fake data, that is probably fine. For a production token that grants access to a real user account or admin panel, it is a genuine security risk. The token could be logged. It could be retained. If their infrastructure were ever compromised, any token you pasted there would be exposed.

This is not a minor implementation detail. It is the entire reason to choose a client-side tool over a server-side one. A JWT that is decoded locally cannot be intercepted, logged, or retained by anyone else. The decoding logic runs on your CPU, in your browser tab, with no outbound connection.

The practical rule: treat every production JWT like a session cookie. You would not paste a session cookie into an external website. Apply the same standard to JWTs. For anything that grants real access, use a local tool or decode it in your own browser console:

// Decode any JWT in your browser console without any tool or library
// Open DevTools (F12), paste this with your actual token:

const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MiIsInJvbGUiOiJlZGl0b3IiLCJleHAiOjE3NTEzMzE2MDB9.signature';

const [header, payload] = token.split('.');

// Base64URL decode each part
const decode = (str) => JSON.parse(atob(str.replace(/-/g, '+').replace(/_/g, '/')));

console.log('Header:', decode(header));
// { alg: 'HS256', typ: 'JWT' }

console.log('Payload:', decode(payload));
// { sub: 'user_482', role: 'editor', exp: 1751331600 }

// Check expiry
const exp = decode(payload).exp;
console.log('Expires:', new Date(exp * 1000).toLocaleString());
console.log('Valid:', exp > Date.now() / 1000);

That snippet works in any modern browser console with no dependencies. It is the same logic that AlteredIdea's JWT Decoder runs, just written out manually. No data leaves your device.

Common JWT problems a decoder helps you diagnose

Most JWT authentication failures come down to one of five things. A decoder reveals all of them instantly.

• •Expired token: the exp claim is a past timestamp. The decoder will show the Expired badge and the exact date and time it expired. Fix: issue a new token via your app's login or token-refresh endpoint.
• •Wrong audience: the aud claim does not match what your API expects. This happens in multi-environment setups where a staging token is used against a production API, or when the auth server is configured with the wrong audience string. Fix: align the aud value in your auth server's token settings with the audience identifier your API checks.
• •Wrong issuer: the iss claim does not match what your server expects. Same root cause as wrong audience, different field. Fix: check the issuer URL set by your auth server versus the issuer your API validates against.
• •Missing claims: a custom claim your application requires (like role, store_id, or permissions) is absent from the payload. Fix: update the token issuance logic in your auth service to include the required claims.
• •Truncated token: the token was cut off during copy-paste or transmission, and the decoder cannot parse it at all. Fix: re-copy the complete token string from the source, making sure all three dot-separated sections are present.