JWT Decoder: How to Decode and Debug JWT Tokens

JSON Web Tokens (JWTs) are widely used for authentication and API sessions. Decoding one is useful for debugging, but it is not the same as trusting it: a JWT decoder reads its contents and cannot prove that the token was signed by the expected issuer.

What a JWT contains

A compact JWT has three dot-separated parts:

header.payload.signature

The header describes the signing algorithm, the payload contains claims such as sub, iss, aud, and exp, and the signature is what a server verifies with the appropriate key. The header and payload are Base64URL-encoded JSON, not encrypted by default.

Decode a JWT in EveryTask

Open the JWT decoder.
Paste a complete three-part token.
Select Decode JWT.
Inspect the header, payload, and any expiration status shown.

The tool decodes the header and payload and calculates whether an exp claim is in the past. It does not verify the signature, issuer, audience, or whether the token has been revoked.

What to check while debugging

exp — expiration time, expressed as Unix seconds.
nbf — a token should not be accepted before this time.
iss — expected issuer.
aud — intended audience.
sub — subject identifier.
scope or role claims — permissions, if your system uses them.

A decoded claim is only a claim. Your application must validate the signature and the claims server-side before granting access.

Keep tokens private

A production JWT can be a credential. Do not paste live customer, employee, or production tokens into a ticket, chat, screenshot, or public tool. Use a short-lived development token or redact the sensitive values when sharing a debugging example.

Also do not put a signing secret or private key into a decoder. Verification belongs in the authentication library or server that owns the key material.

Common JWT problems

“Token has three parts but authentication still fails.” Check signature verification, issuer, audience, clock skew, and token revocation; decoding alone cannot identify all of these.

“The expiration looks wrong.” exp is Unix time in seconds, not milliseconds. A value multiplied twice by 1,000 will produce an implausible date.

“The payload is readable, so is the token insecure?” Readability is expected for a signed JWT. Do not place secrets in a normal JWT payload; use encryption only where your protocol explicitly requires it.

For the encoding itself, see the Base64 guide.

Decode only for inspection

Decoding a JWT is useful when you need to understand why a client received a token, whether a claim is present, or whether an expiration time looks plausible. It is not a login decision. A client can fabricate a token-shaped string with any header and payload it wants, so your server must verify the signature with the trusted key and then enforce issuer, audience, time, and authorisation rules.

That distinction is central to JWT debugging: “I can read the payload” tells you nothing about whether the token should be trusted. Use the decoder to inspect, and use your authentication library or identity provider's server-side verification process to decide.

A safe debugging workflow

Use a short-lived development token or redact values before copying it into a ticket. Decode the header and payload, compare iss, aud, sub, scopes, and time claims with your expected configuration, then inspect the server verification logs. Check clock skew when a token appears to expire immediately or is rejected before nbf.

If an API accepts a token you expected it to reject, investigate its verification configuration rather than assuming the decoder is at fault. If it rejects a token whose payload looks right, investigate the signature key, issuer, audience, algorithm policy, and revocation/session state.

Common claim misunderstandings

sub identifies the subject only by convention; it is not automatically an email address. aud can be a string or list depending on the issuer. scope and role names are application-specific. exp is usually Unix seconds, so treating it as milliseconds produces a wildly wrong date.

Frequently asked questions

Can a JWT decoder verify a signature? Not by merely decoding the three segments; verification needs the correct trusted key and algorithm policy.

Are JWT payloads encrypted? Not normally. Do not place secrets in a standard signed JWT payload.

Should I paste a production token into a public bug report? No. Treat it like a credential.

Keep verification on the server

Use a decoder to inspect a token, but let the server-side authentication code decide whether it is trusted. Signature verification, issuer/audience checks, expiration policy, and authorisation belong in the system that owns the key and access rules.

Treat decoded values as sensitive

Claims can expose identifiers, roles, tenant information, or session data. Redact those values in screenshots and tickets, and rotate a token if it may have been shared outside its intended environment.