JWT Decoder
Decode JWTs locally, inspect header and payload claims, compare expected issuer and audience, check expiration and lifetime, and flag common security risks such as alg=none and sensitive payload fields.
Reviewed May 25, 2026. Privacy model: tool input is processed in your browser and is not uploaded to BytePane servers.
JWT debugging answer
Decode locally, then verify issuer, audience, lifetime, algorithm, and signature server-side
Use this decoder when a token is parseable but your API still returns 401 or 403. Compare the decoded iss, aud, exp, nbf, iat, typ, and alg values against the backend configuration, then verify the signature in trusted server code.
About JWT Decoder
JSON Web Tokens (JWTs) are the standard method for transmitting authentication and authorization claims between a client and server in modern web applications. Defined by RFC 7519, a JWT consists of three Base64URL-encoded parts separated by dots: the header (algorithm and token type), the payload (claims about the user and metadata), and the signature (cryptographic verification). A JWT decoder is an essential debugging tool for developers working with OAuth 2.0, OpenID Connect, and API authentication -- letting you instantly inspect token contents, check expiration times, and verify claim values without writing any code.
JWT Claims Quick Reference
JWTs include registered claims defined by RFC 7519: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration time as Unix timestamp), nbf (not valid before), iat (issued at), and jti (unique token ID). Custom claims like role, email, and permissions are application-specific. The exp claim is critical for security -- tokens should have short lifetimes (15 minutes to 1 hour for access tokens) and be refreshed using longer-lived refresh tokens stored securely.
Common JWT signing algorithms include HS256 (HMAC with SHA-256, using a shared secret), RS256 (RSA with SHA-256, using public/private key pair), and ES256 (ECDSA with P-256 curve). RS256 is recommended for production APIs because the public key can be shared without compromising security, enabling token verification without exposing the signing key. This decoder shows the algorithm in the header, all claims in the payload, and the signature hash -- but does not verify signatures, as that requires the secret key which should never be exposed in a client-side tool.
JWT Security Checks
The security checklist is based on the practical parts of RFC 8725 JWT Best Current Practices and OWASP JWT guidance: whitelist expected algorithms, reject unexpected token types, validate issuer and audience, require expiration, keep access tokens short-lived, and remember that JWT payloads are encoded rather than encrypted. A green checklist item does not mean the signature is valid; it means the decoded token shape looks safer for a verifier to evaluate.
Use the optional expected issuer and expected audience fields when debugging OAuth or OpenID Connect integrations. They help catch a common production bug: the token decodes successfully, but it was issued by the wrong tenant, environment, or authorization server, or it targets a different API audience than the backend accepts.
Frequently Asked Questions
What is a JWT?
JWT (JSON Web Token) is a compact, URL-safe means of representing claims between two parties. It consists of three Base64URL-encoded parts: header, payload, and signature, separated by dots.
Is it safe to paste my JWT here?
All decoding happens entirely in your browser and the token is not sent to BytePane servers. Still avoid pasting production tokens if your team policy forbids it, because anyone with a valid JWT can use it until it expires or is revoked.
Does this tool verify the signature?
No. This tool only decodes and displays JWT contents. Signature verification requires your server secret or public key and must happen in trusted application code, not by pasting production secrets into a browser tool.
What JWT security checks does this decoder run?
It flags common implementation risks from RFC 8725 and OWASP guidance: missing or unsafe algorithms, missing expiration, long-lived access tokens, missing issuer or audience, future nbf/iat values, missing key IDs on asymmetric tokens, and sensitive-looking payload claim names.
Why does my JWT decode but still fail authentication?
Decoding only proves the token is parseable. The backend may still reject it because the signature, issuer, audience, expiration, not-before time, token type, or allowed algorithm does not match the API configuration. Use the expected issuer and audience fields to catch common OAuth/OIDC environment mismatches.