Is my JWT sent to a server?+−
No. Decoding happens entirely in your browser using the Web APIs atob and TextDecoder - the token, and any secret or public key you paste in to verify a signature, never leave your device.
Can this tool verify the signature?+−
Yes, as a best-effort bonus. If you know the HMAC secret (for HS256/384/512) or paste the PEM-encoded public key (for RS256/384/512 or ES256/384/512), the tool checks the signature locally using the browser's Web Crypto API. Without a key, only the header and payload are decoded and shown - decoding never requires the signing key.
Why does it say the algorithm is "none"?+−
"alg": "none" means the token isn't signed at all - anyone could have written any claims into it. Some libraries historically accepted these unsigned tokens as valid, which became a well-known authentication bypass. This tool always flags it prominently so you don't miss it.
What do exp, iat, and nbf mean?+−
They're the standard timestamp claims from RFC 7519: iat is when the token was issued, nbf is the earliest moment it becomes valid, and exp is when it stops being valid. All three are stored as a NumericDate - seconds since the Unix epoch - which this tool converts to a readable date and a relative time like "expires in 2 hours".
Why can I read the payload without a secret?+−
Because a JWT's header and payload are only base64url-encoded, not encrypted - encoding isn't secrecy. Anyone with the token can already read its claims; the signature only proves the claims haven't been tampered with by someone who doesn't hold the key. Never put anything you don't want an attacker to read directly inside a JWT payload.
My token has 3 parts but still won't decode - why?+−
Each of the three segments (header, payload, signature) has to be valid base64url text, and the header and payload have to decode to valid JSON. This tool decodes the header and payload independently and tells you exactly which one is broken and why (bad base64, bad UTF-8, or invalid JSON), instead of just failing silently.