How to Decode a JWT Token and Understand What's Inside

If you've ever worked with a modern API or authentication system, you've almost certainly encountered a JWT — a JSON Web Token. They appear in Authorization headers, cookies, and local storage. But they're not always easy to read at a glance. This guide explains what's inside a JWT and shows you how to decode and inspect one directly in your browser, without installing anything.

What Is a JWT Token?

JWT stands for JSON Web Token. It's a compact, URL-safe format for transmitting claims — pieces of structured data — between parties. JWTs are widely used in authentication flows: when you log in, the server issues a JWT that your client stores and sends with future requests to prove who you are.

A JWT is not encrypted by default. It is encoded, which means the data inside can be read by anyone who has the token. The signature at the end is what makes it tamper-proof — not secret.

The Three Parts of a JWT

Every JWT consists of three parts separated by dots (.):

1. Header — contains metadata, typically the token type (JWT) and the signing algorithm (like HS256 or RS256).

2. Payload — contains the actual claims: user ID, roles, expiry time, issuer, and any custom fields your application includes.

3. Signature — a cryptographic signature created by the server using the header, payload, and a secret key. Verifying this confirms the token has not been tampered with.

Each part is Base64URL-encoded, which is why a raw JWT looks like a long string of random characters split by dots.

How to Decode a JWT in Your Browser

To decode a JWT without any tools or code, use DecoToolkit's JWT Decoder. Paste your token and the tool instantly splits it into three parts and displays the decoded header and payload as formatted JSON.

Steps to decode a JWT:

1. Copy your JWT from the request header, browser DevTools, or your application's storage.

2. Open the JWT Decoder tool.

3. Paste the token in the input field.

4. Read the decoded header and payload immediately — the tool processes everything in your browser with no server-side logging.

Reading the Payload: Common Claims

The payload section of a JWT contains claims — key-value pairs describing the token's purpose and subject. Here are the most common ones:

sub (Subject) — usually the user ID. Identifies who the token belongs to.

iat (Issued At) — a Unix timestamp for when the token was created.

exp (Expiration) — a Unix timestamp for when the token expires. If this is in the past, the request will be rejected.

iss (Issuer) — the entity that issued the token, often a domain or service name.

aud (Audience) — the intended recipient of the token.

roles or scope — custom claims indicating what the user is allowed to do.

To convert an exp timestamp to a readable date, use DecoToolkit's Unix Timestamp Converter alongside the JWT Decoder.

Verifying a JWT Signature (HS256)

Decoding a JWT shows you what's inside, but it does not verify the token is authentic. To verify a JWT with an HS256 signature, you need the secret key used to sign it.

DecoToolkit's JWT Decoder supports HS256 signature verification: enter the shared secret in the verification field and the tool confirms whether the signature is valid. This is useful for sanity-checking tokens during local development.

For RS256 or ES256 tokens — common in production OAuth 2.0 or OpenID Connect systems — verification requires the corresponding public key from the provider's JWKS endpoint. The decoder will still show you the decoded payload; signature verification for asymmetric algorithms requires a separate step.

Common Debugging Scenarios

Token expiry errors: paste the token, check the exp claim, and verify whether it has already expired.

Wrong audience or issuer: middleware validating aud or iss will reject tokens from the wrong source. The decoder shows exactly what the token contains.

Missing roles or scopes: if your API returns 403 Forbidden after a valid login, check whether the expected role or scope is present in the payload.

Different tokens in different environments: the decoded iss claim immediately tells you which environment the token came from.

Unexpected user ID: if data is returned for the wrong user, the sub claim tells you which user the token was issued for.

Security: What Not to Do With a JWT Decoder

Never paste production JWTs into an online tool you don't control. A JWT with a long expiry and broad scopes is essentially a key to your system. Use a trusted tool that processes everything client-side — like DecoToolkit's JWT Decoder — or decode locally using a script.

Never share your JWT in bug reports, Slack messages, or screenshots unless you've already invalidated it. Even a screenshot of DevTools can leak a valid session token.

Never store sensitive data in the payload. Because JWTs are only encoded and not encrypted, anyone who intercepts the token can read the payload. Store only the minimum necessary: typically a user ID and roles, not PII.

Related DecoToolkit Tools

To go deeper with encoding and decoding, explore Base64 Encoder / Decoder — JWT parts are Base64URL-encoded, so understanding Base64 helps you decode tokens manually when needed. Use the Unix Timestamp Converter to convert iat and exp values to readable dates.

Frequently Asked Questions

Is it safe to decode a JWT online?

It depends on the tool. DecoToolkit's JWT Decoder runs entirely in your browser — no data is sent to any server. That makes it safe for development and staging tokens. Avoid pasting long-lived production JWTs into tools you can't verify.

Can I decode a JWT without the secret key?

Yes. Decoding only requires the Base64URL-encoded parts, which anyone with the token can do. The secret key is only needed for signature verification.

What does 'invalid signature' mean?

The signature calculated from the header and payload doesn't match the one in the token. This could mean the token was tampered with, or you're using the wrong secret key.

How do I know if a JWT is expired?

Check the exp claim in the payload. It's a Unix timestamp (seconds since January 1, 1970). If that number is less than the current timestamp, the token has expired. The JWT Decoder highlights expired tokens automatically.

What's the difference between Base64 and Base64URL?

Base64URL replaces + with -, / with _, and removes padding (=). This makes it safe to include in URLs and HTTP headers. JWT parts are Base64URL-encoded, not standard Base64.