Verify & Decode JWT is a free online tool that decodes a JSON Web Token into its three constituent parts — header, payload, and signature — and displays each in a clearly separated, color-coded, pretty-printed view. It also checks the exp (expiration) claim against the current time and, when you supply the signing secret, cryptographically verifies an HS256 signature using the browser's native SubtleCrypto API.
A JWT is three Base64URL-encoded segments joined by dots: a header describing the signing algorithm and token type, a payload holding the actual claims (who the token represents, what it grants, when it expires), and a signature that binds the first two segments together so any tampering can be detected. The critical thing to understand about the first two segments is that Base64URL encoding is not encryption — it is a reversible text encoding, the same category of transformation as Base64 or URL-encoding, with no secret key involved in reading it. Anyone holding a JWT, including a browser extension, a network proxy, or a curious user opening devtools, can decode the header and payload and read every claim inside without knowing anything about how the token was signed. This is precisely why JWTs should never carry passwords, raw credit card numbers, or other genuinely secret data in their payload — only the signature is protected, never the content.
The signature is what actually matters for trust. It proves the token was issued by whoever holds the corresponding signing key and that the header and payload have not been altered since — decoding alone tells you nothing about whether a token is genuine, only what it claims to say. This distinction trips up a surprising number of implementations: code that decodes a JWT to read a user ID but never calls the actual verify function is trusting user-controlled input as if it were authenticated, because a payload can be freely edited and re-encoded by anyone, and only signature verification catches that the resulting token no longer matches what was originally signed.
JWTs use two broad signing approaches. HS256 (HMAC-SHA256) is symmetric — the exact same secret string is used both to sign the token and to verify it, so anyone who can verify a token could also forge one, which makes it appropriate mainly for single-service, first-party use where the signer and verifier are the same system. RS256 and ES256 are asymmetric — the token is signed with a private key that never leaves the issuing server, and verified anywhere using only the corresponding public key, which is why they are preferred whenever multiple independent services need to verify tokens issued by one central authority without being able to forge new ones themselves. This tool implements the interactive verify path for HS256 specifically, since that is the common case for testing tokens issued by your own backend where you already hold the shared secret.
Beyond the signature itself, several standard claims are worth checking manually every time: exp (expiration, a Unix timestamp after which the token must be rejected), iat (issued-at time), nbf (not-before, a time before which the token is not yet valid), iss (issuer), aud (intended audience), and sub (subject, typically the user ID). This tool automatically checks exp against your current system time and reports the token as valid or expired, but every other claim should be reviewed manually against what your application expects, since a syntactically valid, correctly signed token can still carry claims that do not authorize the specific action being attempted.
Need to create a test token instead of inspecting one? Generate JWT Token builds a real, signed HS256 token from a payload and secret.
