Decode JSON Web Tokens instantly. View header, payload, and signature. Debug authentication issues, inspect claims, verify token structure. 100% browser-based—tokens never sent to server.
Test the decoder with this example token:
Getting "Unauthorized 401" errors? Decode your JWT to check if it's expired (exp claim), issued by wrong server (iss), or missing required claims. See exactly what your token contains without server logs.
Curious what data your JWT stores? Decode to see user ID (sub), email, roles, permissions. API returning wrong data? Check if your token has correct user info before blaming the backend.
Token expired? Decode to see exp timestamp. Convert Unix timestamp to readable date. Know exactly when your token expires without making API calls. Perfect for debugging session timeout issues.
OAuth providers (Google, Auth0, Okta) return JWTs. Decode to see scopes, audience, issuer. Verify you're getting correct permissions and claims from identity provider.
Building API? Decode JWTs from Postman/curl requests to verify your auth server generates correct tokens. Check algorithm (alg), issuer (iss), and custom claims before deploying.
App login broken? Copy JWT from device storage/network inspector, decode to see if token format is correct, claims are present, and signature exists. Faster than backend debugging.
header.payload.signature. Paste the whole string exactly as your API returned it.exp, iat, and nbf are Unix timestamps; the decoder shows their human-readable equivalents so you can immediately see whether a token has expired.A JSON Web Token (RFC 7519) is not encrypted — it's merely encoded. Anyone who holds a token can read its contents; that's by design. What the signature provides is integrity: the third segment is a cryptographic signature (typically HMAC-SHA256 or RSA) computed over the first two, so a server can verify the claims weren't tampered with. This distinction matters constantly in debugging: decoding requires no secret, verifying does.
The header declares the signing algorithm ("alg": "HS256" or "RS256" in most real systems). The payload carries claims — registered ones like iss (issuer), sub (subject), aud (audience), and exp (expiry), plus any custom claims your application adds, such as roles or a tenant ID. Because the payload is readable by anyone, it must never contain secrets: no passwords, no API keys, no personal data you wouldn't put in a cookie.
A "401 Unauthorized" that makes no sense — decode the token you're actually sending. Nine times out of ten the exp claim reveals it expired, or the aud doesn't match the API you're calling.
Missing permissions — check whether the expected role or scope claim is present in the payload. If it isn't, the problem lies in token issuance (your identity provider's configuration), not in the API that's rejecting the request.
Clock skew — an nbf (not-before) claim a few seconds in the future, produced by a server whose clock runs ahead, makes freshly issued tokens invalid. The decoded timestamps make this visible instantly. Use our Timestamp Converter to cross-check any Unix time by hand.
Decoding happens entirely in your browser; the token is never transmitted or stored. Still, treat production tokens like passwords as a matter of habit — for live systems, prefer decoding short-lived tokens from a test account.
No — it decodes. Signature verification requires the signing secret (HS256) or the issuer's public key (RS256), which belongs on your server, not in a browser tool. Never treat a decoded token as authenticated.
Check that you copied all three dot-separated segments with no line breaks or trailing whitespace, and that it's actually a JWT — opaque OAuth access tokens from some providers (GitHub, for example) are random strings, not JWTs, and cannot be decoded.
Base64url replaces + and / with - and _ and drops the padding so tokens survive URLs and HTTP headers unmodified. It's why pasting a JWT into a generic Base64 decoder sometimes fails on certain characters.
Common practice is 5–60 minutes for access tokens, paired with longer-lived refresh tokens. Long-lived access tokens are risky precisely because a JWT can't be revoked server-side without extra infrastructure like a denylist.