JWT Decoder
Paste a JWT, read the claims, and optionally verify the original signature locally.
This runs in your browser. Nothing is uploaded.
Verify signature
Decoding is not verification
Anyone can decode a JWT. The header and payload are only encoded, not encrypted. If you paste a secret or PEM public key, this page checks that key against the original signature in your browser. It does not re-sign the token, fetch JWKS, or upload the key. A matching signature is still not a grant of access. Your API must verify tokens itself.
exp, nbf, and iat are shown as UTC time next to the raw unix seconds. Do not paste production tokens into tickets, screenshots, or chat.
Reading the standard time claims
exp is the time after which a token should not be accepted. nbf is the time before which it should not be accepted, and iat is the time at which it was issued. These values are usually Unix seconds, not milliseconds. The decoder shows the number and a UTC date so an obvious unit mistake is easier to spot. Your server still decides which claims are required and how much clock skew it allows.
A readable date is not evidence that the token came from your identity provider. A token can contain a future expiration, a missing expiration, or a claim with the wrong type. Treat every value as untrusted until the receiving service verifies the signature and applies its own authorization rules.
Algorithms and signatures
The header names the signing algorithm in alg. This page highlightsalg: none because a token without a signature cannot establish who created it. Local verification supports HMAC (HS256/384/512), RSA (RS256/384/512 and PS256/384/512), and ECDSA (ES256/384/512) with a key you paste. Other algorithm names stay labels only. The page never re-signs the token to make a wrong key look valid.
Never paste a production token into a bug ticket, chat, or screenshot. Even a token that will expire soon may authorize a real account. If you need to share a reproduction, create a fixture with fake claims and a fake signature. The guideJWT decoded vs verified explains the boundary between inspection and trust.
Local inspection with clear limits
JWT parts are split, Base64url-decoded, and parsed in this browser. The signature part is shown as opaque text because decoding it does not validate it. Nothing is sent to TheDevTab, and the page does not contact an issuer or introspection endpoint. This makes the page useful for inspecting a sample while keeping the token on your device, but it does not replace your security tests.
Use JSON Formatter if you need to inspect a copied claims object after decoding. For a raw exp or iat value, theUnix Timestamp tool can show the same UTC interpretation.
FAQ
Does this JWT decoder upload my token?
No. The token is split and decoded in your browser. After the page loads, it still works in airplane mode. TheDevTab never receives the JWT.
Is decoding the same as verifying a JWT?
No. Decoding reads the header and payload. Verifying checks the original signature with a key you paste. The key stays in this browser and is never uploaded. A verified signature still does not mean your API should trust the claims.
Why do you warn about alg none?
alg none means the token has no signature. Anyone can change the claims. We highlight that so you do not mistake a decoded token for a trusted one.
Is it safe to paste a production token?
Safer here than on a site that uploads it, because we never send it. It is still a secret on your screen. Do not paste tokens into screenshots, tickets, or chat.
What do exp, nbf, and iat mean?
exp is the expiration time, nbf is the not-before time, and iat is the issued-at time. They are usually Unix seconds. The decoder shows the raw value and a UTC date when the claim is numeric.
Can this decoder tell me if a JWT is valid?
It can decode the three parts and, if you paste a key, check whether that key matches the original signature. It does not fetch JWKS, re-sign the token, or apply issuer, audience, or authorization rules. Your application still has to do those checks.