The JWT decoder reads the JSON Web Tokens your APIs issue and consume — the compact header.payload.signature form used by OAuth 2.0, OpenID Connect, and countless auth libraries — and renders them as readable, pretty-printed JSON: the header with its algorithm and key id, the payload with its claims, and the raw signature segment. The decode happens entirely in your browser: base64url-decoding and JSON parsing are local, so the tool is safe to use with production tokens that carry real user identifiers, emails, and session details — nothing is uploaded, logged, or stored. What this decoder will not do is overclaim. It can verify an HMAC signature when you paste the secret: the tool computes the HMAC with WebCrypto and reports Signature valid or Signature invalid, so you can confirm a token was actually signed with the secret you hold and has not been tampered with in transit. That check is honest about its scope: only HS256, HS384, and HS512 can be verified with a shared secret in the browser. Asymmetric tokens — RS256, ES256, PS256 and their siblings — are the norm in production, and verifying them requires the signer's public key, which a client-side tool cannot obtain for you; the decoder says exactly that instead of guessing. Tokens with alg=none, the famously unsafe configuration, are flagged as unsecured with no signature. Expiry and issue-time claims (exp, iat, nbf) appear in their raw epoch form inside the payload JSON, exactly as the token carries them — the tool does not convert or interpret, because silent conversion is where decoders lie. Paste a token from your logs, your network inspector, or your tests and read it as the server would.
Frequently asked questions
Is my token uploaded anywhere?
No. Decoding and signature verification run entirely in your browser with WebCrypto — no network request is made with your token or secret. That makes the tool safe even for production tokens carrying real user claims.
Why can't you verify RS256 tokens?
RS256 and the other asymmetric families are verified with the signer's public key, which lives at the issuer's JWKS endpoint — a client-side tool has no trustworthy way to fetch and trust that key for you. The decoder reports such tokens as unverifiable locally instead of faking a result. HMAC (HS256/384/512) tokens only need the shared secret, so those are checked when you provide it.
What does it mean when a token says alg=none?
alg=none declares the token was not signed at all. Libraries that accept none are the source of infamous authentication bypasses. The decoder flags such tokens as unsecured, with no signature segment to check.
Why are exp and iat shown as raw numbers?
Because that is how the token carries them — NumericDate epoch seconds per RFC 7519. The tool does not silently convert or interpret claims: silent conversion is where decoders lie, and the raw value is the ground truth the server sees.
Can this tool decode OAuth 2.0 access tokens?
Only if they are JWTs. Many providers (Okta, Auth0, Azure AD) issue JWT access tokens, and those decode here. Opaque tokens — random strings that are just identifiers — have no JSON inside and are not JWTs; no decoder can turn those into claims.