JWT Decoder

A JSON Web Token (JWT, defined in RFC 7519) is a compact, URL-safe way of representing a set of claims — statements about a user or session, like "user ID 42, expires at this time, role: admin" — as a signed piece of text that can be passed around in a URL, a cookie, or an HTTP header. A JWT has three dot-separated parts: a header describing the token type and signing algorithm, a payload containing the actual claims, and a signature that lets whoever holds the correct secret (or public key, for asymmetric algorithms) verify the header and payload have not been tampered with since they were signed. The header and payload are not encrypted — they are base64url-encoded, which is a reversible encoding, not a cipher. Anyone who has a JWT can decode its header and payload just by reversing that encoding, with no key, no password, and no special access required; that is exactly what this tool does. This is a deliberate and normal property of JWTs, not a flaw — the security of a JWT comes entirely from its signature, which proves the claims were issued by whoever holds the signing key and have not been altered since, not from hiding the claims' contents. Because of this, JWTs should never contain sensitive data like passwords or full card numbers in their payload — anyone who intercepts the token can read every claim inside it. This is also exactly why this tool's prominent warning matters: decoding a JWT tells you what the payload claims, but it tells you nothing about whether those claims are genuine. A token with a header and payload that decode cleanly could still have an invalid, expired, or entirely absent signature, or have had its payload altered by an attacker who does not know the signing secret but is testing whether anyone bothers to check. Verifying a signature requires the actual signing secret (for HMAC algorithms like HS256) or the issuer's public key (for asymmetric algorithms like RS256), neither of which this decode-only tool has or asks for — and that is intentional, since a tool that could "verify" without the real key would either be lying about verification or would need you to paste a secret into a webpage, which is not something you should ever do with a real signing key. A common practical use of this tool is debugging — checking that your backend issued a token with the claims you expect, confirming an `exp` (expiry) timestamp is set correctly, or inspecting a third-party token during integration work. It is not a substitute for your application's own signature verification, which should always happen server-side using a trusted library and the real secret or public key before any claim in the token is acted upon.