A JWT looks like an unreadable string of random characters, but it's actually three Base64-encoded JSON objects glued together — this tool splits it apart and decodes each piece so you can see exactly what claims and metadata a token actually carries.
An open standard for passing verified claims between systems
JSON Web Tokens were formalized as RFC 7519 in 2015, growing out of earlier work in the OAuth and OpenID Connect communities that needed a compact, self-contained way for one system to prove to another "this user is who they claim to be, and here's some verified information about them" — without requiring a database lookup on every single request. The format's genuine innovation was making tokens self-contained and cryptographically verifiable: a JWT carries its own claims (data) plus a signature that lets any system holding the right key confirm the token hasn't been tampered with since it was issued, all without needing to contact the original issuing server again.
What's actually inside a JWT
A JWT consists of three Base64URL-encoded segments separated by periods: a header (specifying the signing algorithm and token type), a payload (the actual claims — things like user ID, expiration time, and any custom data the issuer included), and a signature (a cryptographic value proving the header and payload haven't been altered). This tool decodes the header and payload segments back into readable JSON — since they're only encoded, not encrypted, this requires no secret key — though it cannot verify the signature's cryptographic validity without knowing the issuer's private key or shared secret.
Where decoding a JWT is genuinely useful
- Debugging authentication issues — inspecting exactly what claims and expiration time a token actually contains is often the fastest way to diagnose why an API request is being rejected or a session is behaving unexpectedly.
- Understanding a third-party API's token structure — when integrating with an identity provider or API that issues JWTs, decoding a sample token reveals exactly what data and claim names you'll be working with.
- Security review and testing — auditing what information a JWT exposes (since anyone can decode the payload without a key) is a standard step in application security testing, since sensitive data should never be placed in an unencrypted JWT payload.
- Learning how token-based authentication works — seeing the actual decoded structure of a real token is one of the clearest ways to understand JWT-based authentication and authorization flows.
Frequently asked questions
Can anyone read the contents of a JWT, even without the secret key? Yes, and this is a critical, often misunderstood point — a standard JWT's header and payload are only Base64-encoded, not encrypted, meaning anyone who has the token can decode and read its contents; the signature only prevents undetected tampering, it doesn't hide the data.
Does this tool verify whether a JWT is genuinely valid? No — verifying a signature requires the issuer's secret key (for symmetric algorithms) or public key (for asymmetric ones), which this tool doesn't have access to; it can only decode and display the token's contents, not confirm they haven't been forged.
Why shouldn't sensitive data be stored in a JWT payload? Because the payload is readable by anyone who intercepts or is given the token — passwords, sensitive personal data or secret internal identifiers should never be placed directly in a JWT's claims unless the token itself is additionally encrypted (using the less common JWE variant of the standard) rather than just signed.
Further reading
RFC 7519 — JSON Web Token (JWT) — The official specification defining JWT structure, claims and signing.
JWT.io — Introduction to JSON Web Tokens — Practical explanation of JWT structure and common use cases in authentication.