Decode, verify, and generate JSON Web Tokens. Runs entirely in your browser.
Enter the secret used to sign the JWT:
JSON Web Tokens (JWT) are an open standard RFC 7519 for securely transmitting information between parties. This tool runs entirely in your browser — tokens and secrets never leave your machine.
A JSON Web Token (RFC 7519) is a compact, URL-safe token made of three Base64URL-encoded segments separated by dots: a header naming the signing algorithm, a payload carrying claims like sub, exp, and iss, and a signature over the first two parts. JWTs are the standard credential format in OAuth 2.0, OpenID Connect, and service-to-service APIs because any party holding the key can verify them without a database lookup.
Only if the decoder runs client-side — pasting a live production token into a tool that ships it to a server hands your session to a stranger. This tool decodes, verifies, and signs entirely in your browser using the Web Crypto API; tokens and secrets never leave your machine, which you can confirm by watching the Network tab in developer tools. Even so, prefer expired or test tokens when sharing screens or screenshots.
No — this is the misconception that causes real breaches. A signed JWT (JWS) is only Base64URL-encoded: anyone who obtains the token can read every claim in the payload without any key. The signature proves who issued the token and that it was not modified; it hides nothing. Never put passwords, API keys, or personal data in JWT claims. If you genuinely need a confidential payload, that is JWE (encrypted JWTs), a separate and much rarer beast.
In decoder mode, paste a token and the header and payload render live, color-coded by segment, with a claims view that translates exp, iat, and nbf timestamps into readable dates. Enter the secret to verify HS256, HS384, or HS512 signatures, with a checkbox for secrets that are themselves Base64URL-encoded. Switch to encoder mode to edit header and payload JSON directly and watch a freshly signed token regenerate on every keystroke.
Usually the secret, not the token. Check whether the issuer stores the secret Base64-encoded — many frameworks do, and you must toggle the Base64URL option here to match. Other classics: a trailing newline or space copied with the secret, an algorithm mismatch (the header says HS512 but the server signs HS256), or a token actually signed with RS256, which needs an RSA public key rather than the shared-secret HMAC verification this tool performs.
Split on dots and decode the middle segment: echo $TOKEN | cut -d. -f2 | base64 -d piped into jq . prints the payload. It often fails with an invalid input error because Base64URL drops padding — append == before decoding, or use base64 -d 2>/dev/null since the payload usually decodes fully before the error. Swap -f2 for -f1 to read the header and check which algorithm signed the token.
When a valid-looking token is rejected, check exp and nbf first — expiry and clock skew between servers cause most failures, which is why validators allow a small leeway. Then confirm aud and iss match what the API expects. On the issuing side: HMAC secrets shorter than 32 characters are brute-forceable with tools like hashcat, and validators must pin accepted algorithms — historic libraries that trusted the header's alg field let attackers downgrade verification entirely.