Why does my JWT show invalid signature with the correct secret?

Common causes: extra whitespace in secret, base64-encoded vs raw secret mismatch, wrong algorithm (HS256 vs HS512), or the token uses RSA/ECDSA (RS256/ES256) which requires a public key not an HMAC secret.

JWT Debugger

Q: How do I check if a JWT is expired without running code?

The exp claim is a Unix timestamp (seconds since epoch). Decode the payload section (the middle part of the JWT between the two dots) from base64url, then compare the exp value to the current Unix timestamp. The JWT debugger does this automatically — it converts exp to a human-readable date and highlights expired tokens. You can also check manually: visit a Unix timestamp converter, enter the exp value, and compare to the current time.

Debug JSON Web Tokens online — decode headers, inspect payload claims, verify HMAC signatures, and check expiry. A privacy-first jwt.io alternative that runs entirely in your browser with no token upload.

Why Use JWT Debugger

JWTs are opaque base64-encoded strings that are impossible to read without decoding. When debugging authentication issues — expired tokens, wrong audience claims, missing scopes, or signature failures — you need to inspect the raw content instantly. This JWT debugger decodes the header, payload, and signature locally in your browser. No token data is sent to any server, making it safe to use with staging and development tokens that may contain sensitive claims.

Instant decode: Paste any JWT and see header, payload, and signature split in milliseconds
Claim inspection: View exp, iat, nbf, sub, aud, and custom claims formatted clearly
Expiry check: Automatically flags expired tokens with human-readable expiry times
HMAC verification: Verify HS256, HS384, and HS512 signatures with your secret key
100% client-side: Token content never leaves your browser — safe for dev/staging tokens

Debug JWT →

Choose the Right Variant

This page: Full JWT debugging — decode, inspect claims, verify signatures, check expiry
Decode JWT Online: Quick decode without verification
JWT Parser: Parse JWT structure and extract individual fields
JWT Token Decoder: Decode JWT token payload and header

Step-by-Step Tutorial

Copy your JWT — a three-part base64url string separated by dots: xxxxx.yyyyy.zzzzz
Paste it into the JWT Debugger input field
The header (algorithm, token type) and payload (claims) are decoded and displayed immediately
Check the exp claim — the tool converts the Unix timestamp to a human-readable date and flags expired tokens
To verify the signature, enter your HMAC secret key and click Verify
Review all claims: sub (subject), aud (audience), iss (issuer), and any custom claims

Real-World Use Case

A backend engineer is debugging a 401 Unauthorized error in a microservices system. The service logs show "Token validation failed" but no specific reason. They copy the JWT from the request headers, paste it into the JWT debugger, and immediately see: the aud claim is api.staging.example.com but the service expects api.example.com. The token was generated by the staging auth service but deployed to production. Fix: update the auth service configuration to use the correct audience for each environment. Total debug time: 90 seconds instead of reading through auth middleware code.

JWT Claims Reference

iss (Issuer): Identifies the principal that issued the token
sub (Subject): Identifies the subject of the token — usually a user ID
aud (Audience): Recipients that the token is intended for — must match the consuming service
exp (Expiration): Unix timestamp after which the token must not be accepted
nbf (Not Before): Unix timestamp before which the token must not be accepted
iat (Issued At): Unix timestamp when the token was issued — useful for detecting clock skew
jti (JWT ID): Unique identifier for the token — used to prevent replay attacks

Common JWT Debugging Scenarios

401 Unauthorized: Check exp (expired?), aud (wrong audience?), iss (wrong issuer?)
Signature invalid: Verify you're using the correct secret — different environments often have different secrets
Clock skew errors: Compare iat and nbf against current time — server clock drift >5 minutes causes failures
Missing scopes: Check custom claims for scope or permissions fields
Wrong algorithm: Header alg field must match what the server expects — RS256 vs HS256 mismatch is common

Privacy and Data Handling

All JWT decoding and verification runs locally in your browser using the Web Crypto API. Your token content — including payload claims like user IDs, emails, and roles — never leaves your device. Even so, avoid pasting production JWTs containing real user data into any online tool. Use tokens from development or staging environments for debugging.

Frequently Asked Questions

Is it safe to paste my JWT into an online debugger?

This JWT debugger runs entirely in your browser — no token data is sent to any server. However, the general principle applies: avoid pasting production JWTs containing real user PII into online tools. Use development or staging tokens for debugging. For RSA/ECDSA signed tokens (RS256, ES256), the payload is readable but the signature requires a private key to forge, so payload inspection is lower risk than HMAC secrets. For maximum security, use the tool in private browsing mode or verify offline by decoding the base64url parts manually.

Why does my JWT show "invalid signature" even with the correct secret?

Common causes: (1) The secret has extra whitespace — copy it carefully, no trailing newlines. (2) The secret is base64-encoded in your auth server config but you're entering the decoded value (or vice versa). (3) The algorithm in the header (alg field) doesn't match — HS256 vs HS512 use different key lengths. (4) The token was signed with an RSA or ECDSA key (RS256, ES256) which requires the public key to verify, not an HMAC secret. Check the alg header field first.

What is the difference between JWT and JWS?

JWT (JSON Web Token) is the general format: a base64url-encoded header, payload, and optional signature separated by dots. JWS (JSON Web Signature) is a JWT with a cryptographic signature — the most common JWT type. JWE (JSON Web Encryption) is an encrypted JWT where the payload is not readable without the decryption key. Most "JWTs" you encounter in authentication systems are technically JWS tokens. If a token has 5 parts (not 3), it is a JWE and the payload cannot be decoded without the private key.

How do I check if a JWT is expired without running code?

The exp claim is a Unix timestamp (seconds since epoch). Decode the payload section (the middle part of the JWT between the two dots) from base64url, then compare the exp value to the current Unix timestamp. The JWT debugger does this automatically — it converts exp to a human-readable date and highlights expired tokens. You can also check manually: visit a Unix timestamp converter, enter the exp value, and compare to the current time.