A complete guide to decoding JSON Web Tokens, why JWTs are encoded rather than encrypted, and why signature verification requires more than this tool can provide.
Launch the JWT Decoder →The JWT Decoder takes a JSON Web Token (JWT) — a compact, URL-safe token format widely used for authentication and authorization in modern web applications and APIs — and decodes its header and payload sections into readable JSON, along with checking and clearly displaying whether the token's expiration claim indicates it has already expired.
A "Load Sample" button fills in an example token for quick experimentation, letting you see exactly how a real JWT's structure maps to the decoded output without needing to find or construct a real token yourself first.
A JWT is always structured as three Base64URL-encoded sections separated by periods: header.payload.signature. The header typically specifies the token type and the signing algorithm used (such as HS256 or RS256). The payload contains the actual claims — the information the token is asserting, such as a user ID, an issuer, an expiration time, and any custom application-specific data. The signature is a cryptographic value computed over the header and payload, using a secret key or private key known only to whoever issued the token, which allows a receiving server to verify the token hasn't been tampered with.
Base64URL encoding, used for all three sections, is a minor variant of standard Base64 encoding specifically modified to be safe for use in URLs and HTTP headers without requiring additional escaping — it replaces the characters + and / (which have special meaning in URLs) with - and _ respectively, and typically omits the trailing padding characters standard Base64 would otherwise include.
This tool's own on-page disclaimer states this directly, and it's worth repeating with full emphasis because it's a genuinely common and consequential misunderstanding: a standard JWT's header and payload are encoded, not encrypted. Base64URL encoding is a reversible, publicly known transformation, not a secret or cryptographic operation in any meaningful sense — anyone who has the token, including this decoder tool, your browser's developer console, or anyone who intercepts it in transit, can read its full contents just as easily as this tool does.
What the signature actually protects is integrity, not confidentiality: it lets a server verify that a token hasn't been tampered with since it was issued (since recomputing a valid signature requires the secret key, which an attacker shouldn't have), but it does nothing to hide the token's contents from anyone who simply looks at it. This is precisely why this tool's disclaimer explicitly warns: never assume a JWT's contents are private, and never put genuinely sensitive information (passwords, full credit card numbers, or similarly sensitive data) directly into a JWT payload, since doing so would expose that information to anyone who gets hold of the token, which, by the very nature of how JWTs are used (sent in HTTP headers, stored in browser local storage, visible in network traffic), is a routine occurrence, not an edge case.
Verifying a JWT's signature requires access to the exact same secret key (for symmetric algorithms like HS256) or the corresponding public key (for asymmetric algorithms like RS256) that the issuing server used to create the signature in the first place. This tool has no way of knowing or obtaining that secret, and for good reason: if any arbitrary website could verify arbitrary tokens' signatures without needing to know the actual secret, that would mean the secret provides no real protection at all.
Because of this, the tool is explicitly limited to decoding the header and payload (the parts that don't require any secret to read) and does not attempt to validate the signature's authenticity. This is the correct, honest behavior for a general-purpose decoding tool: pretending to verify a signature without actually having the means to do so correctly would be actively misleading, potentially giving someone false confidence that a token is legitimate when no such verification actually occurred.
Most JWTs include an exp (expiration) claim in their payload: a Unix timestamp indicating the exact moment after which the token should no longer be considered valid. This tool reads that claim, if present, and compares it against your device's current system clock, clearly indicating whether the token has already expired, is still valid, or doesn't include an expiration claim at all.
It's worth noting that this expiration check, like the rest of this tool's output, is purely informational and based on reading the token's claimed contents — it reflects what the token itself says, not an independent, server-verified confirmation. A tampered token with a fabricated expiration date far in the future would still show as "valid" by this check, since the check only reads the claim, it doesn't verify the signature backing it. Real security-relevant expiration enforcement always happens on the server that issued the token, as part of its own full validation process including signature verification.
JWTs have become one of the most common mechanisms for handling authentication and authorization across modern web and mobile applications, which is exactly why having a quick, trustworthy way to inspect one is broadly useful:
Authorization header of subsequent API requests, letting the server identify and authorize the user without needing to look up a session in a database on every single request.In every one of these contexts, understanding exactly what a given JWT contains, without needing command-line tools or writing custom decoding code, is a genuinely practical, frequently needed capability for anyone working with modern authenticated applications.
exp claim is present.Decoding a typical authentication JWT might reveal a header of {"alg": "HS256", "typ": "JWT"} and a payload containing claims like {"sub": "1234567890", "name": "Jane Doe", "exp": 1735689600}, with the tool checking that expiration timestamp against the current date to report whether the token is still valid.
All decoding happens entirely within your browser using standard Base64URL decoding logic. No network request of any kind is made by this tool, and no token you paste is ever transmitted anywhere, logged, or stored.
Given the earlier point about JWTs not being encrypted, it's worth being extra clear here: while this tool itself doesn't transmit your token anywhere, you should still treat any JWT you're inspecting with the same caution you'd apply to its original context, since its contents are inherently readable by design, not because of anything this tool does or doesn't do.
No. This tool decodes the header and payload only and does not verify the signature, which is the part that actually confirms a token's authenticity. Signature verification requires the issuing server's secret or public key, which this tool has no access to.
Nothing you paste is transmitted anywhere by this tool, but as a general practice, JWTs should never contain genuinely sensitive information in the first place, since their payload is readable by anyone who has the token, independent of any specific tool.
JWT payloads only contain whatever claims the issuing server chose to include. If you expected a specific piece of information and don't see it, the issuing application simply may not include that claim in its tokens.
It means the token's exp claim contains a timestamp earlier than your device's current date and time. A legitimate server receiving this token should reject it for being expired, though this tool's check is informational only and doesn't replicate actual server-side enforcement.