JWT Debugger
Paste a JWT to decode its header, payload, and signature. Validates algorithm, expiration, and claim values without sending the token anywhere.
JWT Debugger
Paste a JSON Web Token to decode its header, payload and inspect the signature.
Paste a JWT β see what's inside in two seconds
Your API keeps returning 401 Unauthorized but the token looks fine at first glance. You copied a JWT from a login response and need to check whether the exp claim has expired. You're integrating with a third-party OAuth provider and want to verify the sub and aud claims before wiring up your auth middleware. Paste the token into the text box and the header, payload, and signature decode instantly β formatted JSON, colour-coded segments, and standard claims extracted into labelled rows.
Click Load sample to see a demonstration token with an expired exp claim, or paste your own token. The three segments appear colour-coded β amber for header, blue for payload, green for signature β so you can visually identify where each part begins and ends. Each decoded section has a Copy button for exporting to your clipboard.
Who uses this JWT debugger
A developer receives a 401 from a protected endpoint. The token exists in the Authorization header but something is wrong. Paste it here and the decoded payload shows whether the exp claim expired three hours ago, whether the iss claim doesn't match the expected issuer, or whether the aud claim points to the wrong service. The answer is visible in two seconds instead of adding debug logs and redeploying.
JWTs are Base64url-encoded, not encrypted β anyone with the token can read the payload. A security reviewer pasting a production token into this tool can immediately see whether sensitive data like email addresses, internal user IDs, or role assignments are exposed in the clear. This is a critical check during OWASP assessments and penetration tests.
Students and junior developers working through OAuth 2.0 or OpenID Connect tutorials benefit from seeing the actual structure of the tokens they receive. The colour-coded three-segment display makes the header.payload.signature format intuitive, and the extracted claims rows show what iat, exp, sub, iss, and aud actually contain in practice.
How a JWT is decoded β and what each part means
The three-part structure
A JWT looks like a long random string, but it's actually three pieces of data joined by dots: header.payload.signature. Each piece is Base64url-encoded β a URL-safe encoding that converts binary data into printable ASCII characters. The encoding is not encryption; it's a reversible transformation, like Base64 but with two character substitutions (+ becomes -, / becomes _) and the trailing = padding stripped. Anyone with the token can decode it.
What happens when you paste a token
The debugger splits the string at each dot. A valid JWT has exactly three segments β if you get two or four, it's not a standard JWT. Each segment is Base6url-decoded by restoring the padding, reversing the character substitutions, and decoding the resulting bytes as UTF-8. The header and payload are then parsed as JSON. The signature is displayed as-is, because verifying it requires the original signing key which only the issuer has.
Worked example: the sample token
The sample token's header decodes to show alg: HS256 and typ: JWT β it's an HMAC-SHA256 signed token of type JWT. The payload decodes to show sub: 1234567890, name: John Doe, iat: 1516239022, and exp: 1735089600. The iat (issued at) is January 19, 2018. The exp (expiration) is December 25, 2024 β which means this token is expired. The debugger flags it with a warning. The signature segment is the cryptographic proof that the payload hasn't been tampered with, but the tool can't verify it without the server's secret key.
What the decoded claims tell you
The sub claim identifies who the token belongs to β usually a user ID. The iss claim (if present) identifies who issued it. The aud claim identifies which service it's intended for. The exp claim is a Unix timestamp indicating when the token expires. The iat claim records when it was created. If any of these claims don't match what your server expects β wrong issuer, expired timestamp, unexpected audience β your API will reject the token with a 401.
Important: this tool decodes but does not verify
The signature is displayed but not validated. To verify a signature, you'd need the server's secret key (for HMAC algorithms) or public key (for RSA/ECDSA). This is a deliberate limitation β the debugger is for inspection, not security validation. A decoded payload is only trustworthy if you trust the issuer. An attacker can craft a JWT with any payload they want; the signature is what makes it valid, and only the signing party can produce a valid one.
Frequently Asked Questions
Can this tool verify the JWT signature?
No. Signature verification requires the secret key or RSA public key, which is a server-side operation. This tool decodes and displays the header and payload, but cannot confirm the signature is valid β only your server can do that. A decoded JWT is readable, but authenticity can only be confirmed by cryptographic verification against the original signing key.
Is it safe to paste my JWT here?
Yes. The decoding happens entirely in your browser β no data is sent to any server, no cookies are set, no network requests are made. The token stays in your browser's memory and is gone when you close the tab. That said, avoid pasting production tokens with sensitive claims (like admin privileges or personal data) into any online tool as a general security practice.
What does the exp claim mean?
The exp (expiration time) claim is a Unix timestamp β seconds since 1 January 1970 β indicating when the token expires. The debugger converts it to a human-readable UTC date and flags expired tokens by comparing against your system clock. A token with exp 1735089600 expired on 25 December 2024. Consuming services should reject expired tokens, though some implementations allow a short grace period.
What is the difference between HS256 and RS256?
HS256 uses a shared secret (symmetric) β the same key signs and verifies. RS256 uses RSA key pairs (asymmetric) β the server signs with a private key, anyone can verify with the public key. RS256 is preferred when multiple services need to verify tokens without sharing a secret, such as in microservice architectures or when third-party services need to validate your tokens.
Why is the payload not encrypted?
JWTs are Base64url-encoded, not encrypted. The payload is readable by anyone who intercepts the token β this is by design. The signature ensures integrity (the payload hasn't been tampered with) and authenticity (it was signed by the expected issuer), but does not provide confidentiality. If the payload contains sensitive data, use JWE (JSON Web Encryption) or transmit the JWT over TLS only.
What happens if I paste a JWE or non-JWT token?
JWE tokens have five dot-separated segments and will trigger a validation error because this tool expects the three-segment JWS format. Non-JWT tokens like opaque session IDs or SAML assertions don't follow the dot-separated structure and will also be rejected with a descriptive error message.
What is Base64url and why is it different from Base64?
Base64url (RFC 4648 Β§5) is a URL-safe variant of Base64 encoding. It replaces the + character with - and / with _, then strips trailing = padding. Standard Base64 uses + and / which are not safe in URLs and filenames. JWTs use Base64url so the token can be safely included in HTTP headers, query parameters, and URLs without additional escaping.