UseToolSuite UseToolSuite

JWT Decoder

Decode and inspect JWT tokens online without verification. Instantly view the header, payload claims, and expiration date — all processed locally in your browser.

Last updated

JWT Decoder is a free, browser-based tool from UseToolSuite's Encoding & Decoding Tools collection. All processing happens locally on your device — your data is never uploaded to any server. Use the tool below, then scroll down for detailed documentation, frequently asked questions, and related resources.

Advertisement

Zero-Knowledge JWT Debugger

The JWT Debugger is an elite, privacy-first utility that lets you decode JSON Web Tokens entirely offline. Because the tool executes exclusively in your browser using native JavaScript and the `Web Crypto API`, your sensitive access tokens, payloads, and cryptographic secrets are never transmitted to any external server.

Cryptographic Signature Verification

Verify the authenticity of your tokens locally. By utilizing the native window.crypto.subtle interface, this tool can instantly validate HMAC SHA-256 (HS256) secrets and RSA (RS256) public key certificates without any backend round-trips. This guarantees absolute zero-knowledge security for your debugging sessions.

HS256 vs RS256: Which algorithm to use

Feature HS256 (HMAC) RS256 (RSA)
Key typeShared secretPublic/private key pair
VerificationRequires the secretPublic key only
PerformanceFasterSlower (asymmetric)
Best forSingle-service appsMicroservices, OIDC, third-party verification

Use HS256 when the same service creates and verifies tokens. Use RS256 when multiple services need to verify tokens without sharing a secret — common in OAuth 2.0 and OpenID Connect architectures.

The registered claims, decoded

ClaimNameWhat to check
issIssuerMatches the auth server you expect
subSubjectThe user/principal ID — stable across sessions
audAudienceContains your service; reject tokens meant for others
expExpirationSeconds (not ms) since epoch; in the future
nbfNot beforeToken invalid until this time
iatIssued atUseful for measuring token age
jtiJWT IDUnique ID, enables revocation lists

The most commonly skipped check in real codebases is aud — without it, a token issued for one microservice can be replayed against another service that shares the same signing key.

Debugging the three usual failure modes

Signature invalid: you’re verifying with the wrong key (rotated keys, wrong environment), the wrong algorithm family (HS256 secret used against an RS256 token), or the token was truncated in transit — check for a missing final segment after the second dot.

Token rejected as malformed: JWTs use base64url (- and _) without padding; a token that went through a strict standard-Base64 decoder somewhere in your pipeline gets corrupted. URL-encoding a token inside a query string can also mangle it.

Claims look wrong: decode here and read the raw payload. A surprising number of “auth bugs” are just the issuer putting a claim under a different name (userId vs sub) or nesting custom claims under a namespace URL, as Auth0 and others do.

Token hygiene for builders

Keep payloads small — JWTs travel on every request, and a kilobyte of user profile in the token is a kilobyte of header overhead per call. Set expiry short (minutes for access tokens) and pair with refresh tokens; long-lived bearer tokens are stolen-credential time bombs. And never put secrets in the payload: a JWT is signed, not encrypted — anyone holding it can read everything, exactly as this decoder demonstrates.

How helpful was this tool?

Click to rate

Advertisement

Key Concepts

Essential terms and definitions related to JWT Decoder.

JWT (JSON Web Token)

A compact, URL-safe token format defined by RFC 7519 for securely transmitting information between parties as a JSON object. A JWT consists of three Base64URL-encoded parts separated by dots: header (algorithm and type), payload (claims), and signature (verification data). JWTs are widely used for stateless authentication in REST APIs.

JWT Header

The first segment of a JWT token containing metadata about the token itself: the signing algorithm (alg) such as HS256 or RS256, and the token type (typ), which is typically "JWT". The header is Base64URL-encoded and determines how the signature is computed and verified.

JWT Payload (Claims)

The second segment of a JWT containing the actual data as key-value pairs called "claims." Standard claims include: iss (issuer), sub (subject), exp (expiration time), iat (issued at), and aud (audience). Custom claims can carry any application-specific data such as user ID, roles, or permissions.

JWT Signature

The third segment of a JWT that ensures the token has not been tampered with. It is created by signing the encoded header and payload with a secret key (HMAC) or a private key (RSA/ECDSA). The recipient verifies the signature using the shared secret or the corresponding public key. This tool does not verify signatures — it only decodes and displays content.

Frequently Asked Questions

Does this tool verify the JWT signature?

No. This tool decodes and displays the JWT header and payload without verifying the signature. It is a debugging and inspection tool, not a security validation tool. Never trust a JWT solely based on its decoded content without signature verification.

Can I decode expired JWT tokens?

Yes. The decoder displays the token contents regardless of expiration status. It will show the exp (expiration) claim in the payload so you can see when the token expired, but it does not prevent you from viewing expired tokens.

What JWT algorithms does the decoder display?

The decoder shows whatever algorithm is specified in the JWT header (alg field), such as HS256, RS256, ES256, or none. It displays this information but does not perform any cryptographic operations.

Is it safe to paste my production JWT tokens here?

Yes, because all decoding happens locally in your browser. No data is sent to any server. However, you should still be cautious about sharing decoded token contents, as JWTs often contain sensitive user claims and permissions.

Why does a token that works in my app show as expired here?

Check the units first: exp is defined as seconds since the Unix epoch, but tokens minted by code that passed JavaScript's Date.now() (milliseconds) directly will carry a far-future or seemingly-invalid timestamp. Also remember exp is evaluated against your machine's clock — a few minutes of clock skew between server and client can make a fresh token look expired or a stale one look valid.

What is the alg=none vulnerability?

Early JWT libraries accepted tokens whose header declared "alg": "none" — meaning no signature at all — letting attackers forge arbitrary payloads. Modern libraries reject it by default, but the lesson stands: the verifying side must enforce its own expected algorithm and never trust the algorithm declared inside the token it is verifying.

Troubleshooting & Technical Tips

Common errors developers encounter and how to resolve them.

InvalidTokenError: Invalid JWT structure — 3 segments expected

A valid JWT token consists of three segments in the header.payload.signature format, separated by dots (.). If you get a "jwt malformed" or segment count error, make sure the token was copied completely — especially with long tokens, characters may be truncated from the beginning or end during copy-paste. Remember to remove the Bearer prefix ("Bearer ") since many HTTP Authorization headers prepend it to the token. Paste it into this tool to quickly validate the token structure.

Invalid Signature: HS256 vs RS256 algorithm mismatch

If JWT signature verification is failing, check the alg (algorithm) field in the header. HS256 (HMAC-SHA256) uses a symmetric secret key, while RS256 (RSA-SHA256) uses an asymmetric public/private key pair. Verifying with the wrong key type will always produce an "invalid signature" error. Important security note: never accept alg:"none" — this is a known JWT attack vector that bypasses signature verification (CVE-2015-9235).

Payload parsing error: Corrupted JSON during Base64URL decode

JWT payloads are encoded with URL-safe Base64 (Base64URL), not standard Base64: + is replaced with -, / with _, and padding (=) is removed. If you try to manually decode the payload without accounting for this difference, atob() will throw an invalid character error or produce corrupted JSON output. Also verify that the payload is valid JSON — some legacy implementations may have non-JSON payloads. This tool automatically handles Base64URL conversion and displays the parsed JSON.

Token expired (exp claim): Timing and clock skew issues

The exp (expiration) claim in a JWT is stored as a Unix timestamp. If you get a "Token expired" error, check that the server clock is accurate — clock skew between client and server can cause the token to expire prematurely. As a best practice, allow a 30-60 second clock skew tolerance in JWT verification. Use this tool to decode your token and inspect the exp, iat (issued at), and nbf (not before) claim values.

Related Guides

In-depth articles covering the concepts behind JWT Decoder.

Advertisement

Related Tools