UseToolSuite UseToolSuite

JWT Decoder

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

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.

JWT Decoder Powered by UseToolSuite — free browser tools

JWT Decoder encodes and decodes locally, so nothing you paste is ever transmitted. It's one of the free Encoding & Decoding Tools on UseToolSuite.

Last updated

How helpful was this tool?

Click to rate

Embed this tool on your site

Paste this snippet into any HTML page or blog post to embed a live, fully working copy of JWT Decoder. Free for any use.

Key Concepts

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

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

GUIDE

HTTP Status Codes: The Complete Guide for Developers

A complete guide to HTTP status codes: 401 vs 403, the SEO impact of 301 vs 302, 409 for optimistic locking, and how to monitor 5xx errors properly.

GUIDE

Web Security: Encoding and Hashing Guide

Encoding vs hashing vs encryption: when to use Base64, SHA-256, bcrypt, AES, and HTML entity encoding for web security — with examples and decision trees.

JWT Security: What's Safe to Decode, and What You Should Never Paste Online

A JWT is just Base64 — anyone can read it. How to inspect tokens safely, why pasting a live token into a random site is risky, and how signatures protect you.

API Authentication Methods Compared: API Keys, OAuth 2.0, JWT, HMAC & mTLS

API authentication compared: API keys, Basic auth, Bearer tokens, OAuth 2.0, JWT, HMAC request signing, and mutual TLS — and when to use each.

Related Tools

Base64 Encoder / Decoder

Encoding & Decoding Tools

Hash Generator

Encoding & Decoding Tools

URL Encoder / Decoder

Encoding & Decoding Tools

JWT Token Builder

Encoding & Decoding Tools