JWT Debugger & Inspector

The complete guide to JSON Web Tokens

What is a JWT?

A JSON Web Token (JWT, pronounced "jot") is an open standard (RFC 7519) for representing a set of claims — small pieces of information about a user or session — as a compact, URL-safe string that can be verified and trusted because it's digitally signed. Instead of a server having to look up a session in a database on every request, a JWT carries its own data and proof of authenticity, which the receiving server can check on its own using math rather than a database round-trip. This makes JWTs a natural fit for stateless APIs, single-page apps, mobile clients, and systems split across many services.

JWT structure: three parts, two dots

Every JWT has the shape header.payload.signature — three base64url-encoded segments joined by periods. Splitting a token on its dots and decoding each segment is exactly what this tool's decoder does the instant you paste a token, with no key required for that first step.

The header, explained

The header is a small JSON object describing the token itself — most importantly alg (the signing algorithm, like HS256 or RS256) and typ (almost always "JWT"). Some tokens also include a kid (key ID) so the verifier knows which of several possible keys to use. The header is what tells a verifier how to check the signature — which is also exactly why a verifier must never blindly trust the alg value from an untrusted token (see the "none" algorithm attack under Security below).

The payload, explained

The payload is where the actual claims live — the data the token is asserting, such as who the user is, what they're allowed to do, and when the token expires. Claims come in three flavours: registered claims (standardized names with defined meaning, like exp and sub), public claims (custom names meant to be collision-resistant and ideally registered in the IANA JWT registry or namespaced with a URI), and private claims (custom names agreed upon between the parties using them, like role or tenant_id). This tool's claims table automatically separates registered claims — with human-readable dates and expiry countdowns — from everything else.

The signature, explained

The signature is computed by taking the encoded header and payload, joining them with a dot, and running that string through a cryptographic signing algorithm (HMAC for symmetric algorithms, or RSA/ECDSA private-key signing for asymmetric ones) using a secret or private key. Anyone can decode the header and payload without any key — but only someone who recomputes this exact signature with the correct secret or key can prove the token is authentic and unmodified. That recomputation and comparison is precisely what this tool's Verify panel does.

JWT vs. session-based authentication

Traditional session authentication issues a random session ID, stores the actual user data server-side (in memory, Redis, or a database), and looks it up on every request. JWTs flip this: the token itself carries the claims, so any server holding the right verification key can validate it without a shared datastore — which is why JWTs scale so naturally across multiple stateless API servers or microservices. The trade-off is revocation: a session can be deleted server-side instantly, while a JWT remains valid until it expires unless you build additional infrastructure (a token blocklist, short expirations plus refresh tokens, or key rotation) to revoke it early.

Base64URL encoding

JWTs use Base64URL rather than standard Base64 — it replaces the + and / characters (which have special meaning in URLs) with - and _, and drops the trailing = padding, making the result safe to embed directly in URLs, cookies, and HTTP headers without escaping. Critically, Base64URL is encoding, not encryption — decoding requires no secret at all, which is why this tool (and any JWT decoder) can show you the header and payload of any token instantly, valid or not.

JWT signing algorithms

The alg header claim determines how a token is signed and verified. This tool supports verification for the algorithm families actually in common use: HS256/384/512 (HMAC with SHA-256/384/512 — symmetric, one shared secret), RS256/384/512 (RSASSA-PKCS1-v1.5 with SHA-256/384/512 — asymmetric, RSA key pair), PS256/384/512 (RSA-PSS — a more modern, provably-secure RSA padding scheme), and ES256/384 (ECDSA over the P-256/P-384 curves — asymmetric, smaller keys and signatures than RSA). A token declaring alg: "none" is explicitly unsigned and must never be accepted by a real verifier — this tool flags it immediately as a critical security issue.

HS256 vs. RS256: which should you use?

HS256 is simplest when a single backend both issues and verifies its own tokens — one secret does both jobs, but that secret must stay confidential everywhere it's used, and anyone who has it can forge valid tokens. RS256 (or ES256) separates signing from verification: a private key signs tokens on one trusted issuer, while any number of other services can verify using only the corresponding public key, which is safe to distribute freely since it can't be used to create new valid signatures. This is why RS256/ES256 are the standard choice for OAuth/OIDC identity providers and any system where multiple independent services need to verify tokens they didn't issue themselves.

How signature verification actually works

Verification recomputes the exact same signing operation the issuer performed — hashing the header-and-payload string with the algorithm named in the header, using the secret (HMAC) or private key (RSA/ECDSA signing on the issuer's side, public key checking on the verifier's side) — and compares the result to the signature segment of the token. If they match, the token's header and payload have not been altered since signing, and (for asymmetric algorithms) came from someone holding the private key. If they don't match — wrong key, wrong algorithm, or tampered content — verification fails, which is exactly the "Invalid signature" result you'll see in the Verify panel.

JWT security fundamentals

The single most important fact about JWTs: the header and payload are encoded, not encrypted. Anyone who intercepts a token — a browser extension, a proxy log, a curious user with dev tools open — can read every claim inside it without any key. Never place passwords, full credit card numbers, or other genuinely secret data in a JWT payload. Separately, verifiers must be coded defensively: never trust the alg header from an incoming token to decide how to verify it (the classic "alg confusion" and "none algorithm" attacks exploit servers that do this), always check exp server-side even though most libraries do this automatically, and prefer asymmetric algorithms (RS/ES) whenever multiple services need to verify tokens they didn't issue.

Expiration and other time-based claims

exp (expiration time) and nbf (not before) are Unix timestamps — whole seconds since January 1, 1970 UTC — that define the window during which a token should be accepted. iat (issued at) records when the token was created and is often used to compute a token's total intended lifetime (exp − iat). This tool converts all three to readable local dates plus a human "in 2 hours" / "3 days ago" countdown, and flags tokens with no exp at all — such tokens never expire by design, which is rarely what you actually want.

Refresh tokens

Because a compromised long-lived JWT is hard to revoke, most real systems issue short-lived access tokens (minutes to a couple of hours) alongside a separate, longer-lived refresh token that's used only to obtain a new access token from the auth server — never sent directly to APIs. This limits how long a stolen access token remains useful, while refresh tokens themselves can be revoked server-side (since redeeming one requires a round-trip to the issuer) even though the access tokens they produce cannot be individually revoked before they expire.

JWT, OAuth 2.0 and OpenID Connect

JWT is a token format; OAuth 2.0 is an authorization protocol for how a user grants an application limited access to their data; OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 specifically for authentication. In a typical OIDC flow, the identity provider issues a JWT "ID token" (proving who the user is) and often a JWT or opaque "access token" (proving what the app is allowed to do) — this tool is a natural companion for inspecting exactly those tokens while building or debugging a login flow.

API authentication with JWT

A typical JWT-secured API flow: the client authenticates once (username/password, OAuth, etc.) and receives a signed JWT; the client then sends that token on every subsequent request, almost always in the Authorization: Bearer <token> HTTP header; the API verifies the signature and checks claims like exp, aud (is this token meant for me?) and iss (did I actually issue or trust this token's issuer?) before trusting any of the claims inside to make an authorization decision.

Common JWT mistakes

• Storing sensitive data in the payload — passwords, full card numbers, or private personal data have no business inside a JWT, since anyone can decode it.
• Trusting the client-supplied alg header without pinning the expected algorithm server-side, opening the door to algorithm-confusion attacks.
• No expiration claim, or an expiration so far in the future it's effectively permanent.
• Using HS256 with a weak, short, or guessable secret — HMAC secrets should be long, random, and generated with a proper tool, not a memorable phrase.
• Storing JWTs in localStorage in a way that's readable by any injected script (XSS), instead of an HttpOnly cookie where practical.
• Never rotating signing keys, which turns any eventual key leak into an indefinite compromise.

Debugging JWTs in practice

Most real-world JWT bugs fall into a handful of buckets this tool is built to surface immediately: a token that looks fine but fails verification (usually the wrong secret/key, or a mismatched algorithm between issuer and verifier); a token rejected as expired sooner than expected (check both exp and your server's clock — clock drift between services is a classic culprit); claims missing that your application expects (compare the payload against what your issuing code is supposed to set); and malformed tokens from a copy-paste error (missing a segment, extra whitespace, or truncation) — the decoder reports exactly which segment failed to parse rather than a generic failure.

JWT best practices checklist

• Always set a short, sensible exp — minutes to a few hours for access tokens, not days or "never."
• Prefer RS256/ES256 over HS256 whenever more than one service needs to verify tokens.
• Pin the expected algorithm(s) in verifier code — never derive verification behaviour from the token's own header.
• Never store secrets, passwords, or highly sensitive personal data in the payload.
• Use refresh tokens for long-lived sessions instead of long-lived access tokens.
• Validate aud and iss, not just the signature — a validly signed token from the wrong issuer or meant for a different audience should still be rejected.
• Rotate signing keys periodically and support multiple valid keys via kid during rotation windows.

Troubleshooting common errors

• "This does not look like a JWT" — check for missing dots, extra whitespace/newlines, or that you copied the complete token including all three segments.
• "Invalid signature" — double-check you're using the exact secret/key the token was actually signed with, and that the algorithm matches (HS secrets and RS/ES public keys are not interchangeable).
• "Invalid header/payload — could not decode" — the base64url segment itself is corrupted, often from a copy-paste that dropped characters or added line breaks.
• Token "expired" immediately after being issued — check your server's clock is correctly synced (NTP), and confirm exp is in seconds, not milliseconds (a very common off-by-1000 bug).

Summary

A JWT is a signed, self-contained bundle of claims — readable by anyone, but only trustworthy once its signature is verified against the correct key. This tool decodes instantly with no key needed, runs a genuine cryptographic verification when you provide one, and layers on the claim analysis and security warnings a real debugging session actually needs. Paste a token above to get started.