JWT Decoder & Inspector

This free online JWT decoder reads a JSON Web Token and shows you exactly what is inside it: the header, the payload, and every claim. Paste a token — or a full Authorization: Bearer header — and the decoder instantly parses the Base64URL segments into readable JSON, extracts the claims into a searchable table, and calculates expiration and not-before status with a live countdown.

It is built for developers debugging API authentication: backend, REST API, OAuth 2.0, OpenID Connect, and especially C#, .NET, and ASP.NET Core developers working with bearer tokens. Everything runs locally, so it is safe to use while you troubleshoot.

Decoding is not verification. Being able to decode a token does not prove it is authentic. Signature verification is not performed by this tool.

JWT stands for JSON Web Token — a compact, URL-safe way to represent claims between two parties. JWTs are widely used for authentication, authorization, API access, and carrying identity claims. A signed JWT (technically a JWS) has three Base64URL-encoded parts separated by dots:

header.payload.signature

The header describes the token type and signing algorithm, the payload carries the claims, and the signature lets a server verify the token's integrity using the appropriate key.

1. Copy your JWT (or the whole Authorization header).
2. Paste it into the JWT decoder above.
3. Inspect the decoded header (alg, typ, kid).
4. Inspect the payload and claims in the Claims tab.
5. Review expiration, not-before, and timestamp details.
6. Check the Signature tab — present, but not verified.
7. Remember: decoding does not verify the signature or the issuer.

The header is a small JSON object. Common fields include:

• alg — the signing algorithm declared by the token (for example HS256, RS256, or ES256).
• typ — the token type, commonly JWT.
• kid — a key ID identifying which signing key the issuer used.

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "example-key"
}

Note that the alg value is only a declaration — it does not prove the token was actually signed with that algorithm. That is confirmed during signature verification.

The payload contains claims — statements about the subject and the token. Some are standardized registered claims (like iss, sub, aud, exp, iat, nbf, and jti); others are custom claims defined by your application, such as role or scope.

{
  "sub": "12345",
  "role": "admin",
  "department": "engineering"
}

The meaning of custom claims depends entirely on the issuer and application, so this tool labels them as custom rather than inventing a definition.

The signature is created by signing the encoded header and payload with a secret (HMAC — HS256/384/512) or a private key (RSA — RS256/384/512, or ECDSA — ES256/384/512). A server verifies it using the shared secret or the issuer's public key.

This tool displays the signature for inspection but never treats a token as verified simply because a signature is present. Verifying a JWT is a separate, cryptographic operation that requires the correct key.

The decoder automatically recognizes the registered claims and explains them:

• iss — issuer: who issued the token.
• sub — subject: who the token is about.
• aud — audience: who the token is for (string or array).
• exp — expiration time.
• nbf — not before: earliest acceptable time.
• iat — issued at.
• jti — a unique token identifier.

The exp, iat, and nbf claims are NumericDate values — the number of seconds since the Unix epoch (1970-01-01 UTC). The decoder converts each one to your browser local time and UTC, and shows a live countdown for expiration.

A token that is not expired is not automatically valid — expiration is only one of several checks. Conversely, a missing exp claim does not by itself make a token invalid; some tokens legitimately have no expiration claim.

This is the most important distinction when working with tokens. The tool's purpose is decoding and inspection, not validation.

Signature verification is not performed by this tool. Always verify the signature, issuer, audience, and expiration in your application before trusting a token.

Decoding a JWT you already possess is safe — you are only reading data you hold. The important caution is about where you paste tokens: never paste real production access tokens or refresh tokens into tools you do not trust, because a malicious tool could exfiltrate them.

This decoder processes your token locally in your browser. It is never uploaded to our server, logged, stored in localStorage or cookies, sent to analytics, or added to the URL. Refreshing the page discards it.

The header and payload are encoded with Base64URL — a URL-safe variant of Base64. This is important: Base64URL is encoding, not encryption. Anyone who obtains a signed JWT can decode and read its payload, so you should avoid putting passwords, secrets, or highly sensitive personal data in JWT claims.

• JWT — a JSON Web Token: a compact representation of claims.
• JWS — a signed token whose integrity and authenticity can be verified with the appropriate key. The readable tokens you usually see are JWS.
• JWE — an encrypted token whose contents cannot be read by Base64URL decoding alone; it requires a decryption key.

This tool is designed for inspecting readable JWT/JWS compact tokens. An encrypted JWE (five segments) cannot be decoded into readable claims here.

ASP.NET Core applications commonly protect APIs with JWT bearer authentication. The framework validates the token — signature, issuer, audience, and lifetime — and turns the claims into a ClaimsPrincipal your code can read. A minimal configuration looks like this:

builder.Services
    .AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        options.Authority = "https://auth.example.com";
        options.Audience = "my-api";
    });

Actual configuration depends on your identity provider. Decoding a token in the browser is great for debugging what a client received, but the server must always perform proper cryptographic validation.

This decoder helps you troubleshoot common authentication issues:

• Expired access tokens (check exp)
• Wrong audience (aud mismatch)
• Wrong or untrusted issuer (iss)
• Missing claims, roles, or scopes
• Tokens that are not active yet (nbf in the future)
• Differences between environments (staging vs production)

When a request still fails after the token looks correct here, investigate the server side too — signature verification, clock skew, and validation configuration all happen on the server and won't be visible from decoding alone.

What is a JWT decoder?

A JWT decoder is a tool that reads the Base64URL-encoded header and payload of a JSON Web Token and shows them as readable JSON, along with the token's claims, timestamps, and expiration. This one runs entirely in your browser.

How do I decode a JWT token?

Paste your JWT (or an Authorization: Bearer header) into the input. The tool automatically decodes the header and payload, lists the claims, and calculates expiration and not-before status. No button or sign-up is required.

Is JWT decoding the same as JWT validation?

No. Decoding only reads the header and payload. Validation additionally verifies the cryptographic signature, checks the issuer and audience, and confirms the token has not expired. This tool decodes and inspects — it does not verify the signature.

Can I decode a JWT without a secret?

Yes. The header and payload of a JWT/JWS are only Base64URL-encoded, not encrypted, so they can be read without any key. You only need a key to verify the signature or to decrypt an encrypted JWE token.

Is a JWT encrypted?

A standard signed JWT (a JWS) is not encrypted — its payload is readable by anyone who has the token. Only a JWE (encrypted JWT) protects the contents, and it cannot be decoded into readable claims without the decryption key.

Can anyone read a JWT payload?

Yes. Because the payload is Base64URL-encoded rather than encrypted, anyone who obtains the token can read its claims. For this reason you should never place secrets or highly sensitive data in a JWT payload.

What does the JWT expiration claim mean?

The exp claim is a NumericDate (Unix seconds) indicating the time after which the token should no longer be accepted. This tool converts it to your local time and UTC and shows a live countdown.

What is the difference between iat, exp, and nbf?

iat (issued at) is when the token was created, exp (expiration) is when it stops being valid, and nbf (not before) is the earliest time it may be accepted. All three are NumericDate values measured in seconds since the Unix epoch.

What does the JWT iss claim mean?

The iss (issuer) claim identifies the party that issued the token, such as your identity provider or authorization server. Applications typically validate it against a trusted issuer value.

What does the JWT aud claim mean?

The aud (audience) claim identifies the intended recipient(s) of the token — often an API. It can be a single string or an array; this tool renders both. Your API should confirm it is the intended audience.

Can I decode a JWT access token?

Yes. Access tokens issued as JWTs can be decoded and inspected here, including bearer tokens copied from an Authorization header. The tool strips a leading Bearer prefix automatically.

Does this tool verify JWT signatures?

No. Signature verification is not performed by this tool. It is a decoder and inspector. Always verify the signature, issuer, and audience in your server-side application using the appropriate key.

Is this JWT decoder free?

Yes, it is completely free with no sign-up, no usage limits, and no ads inside the tool.

Is my JWT uploaded to a server?

No. The token is decoded locally in your browser using JavaScript. It is never uploaded, logged, stored, or added to the URL. Refreshing the page clears it.

Can I use this tool for ASP.NET Core JWT debugging?

Yes. It is well suited to debugging ASP.NET Core and .NET bearer authentication — inspecting claims, roles, scopes, audiences, issuers, and expiration while you troubleshoot 401/403 responses.