What is a JWT?
A JSON Web Token (RFC 7519) is a compact, URL-safe token format for representing claims between two parties. It has three Base64URL-encoded segments separated by dots: a header (algorithm and token type), a payload (the claims — e.g. user ID, expiry, roles), and a signature (proves the header and payload were not tampered with, if you hold the signing key).
Is decoding a JWT the same as verifying it?
No. Decoding just Base64URL-decodes the header and payload — anyone can do this without any key, because JWTs are signed, not encrypted, and the claims are plainly readable to anyone who has the token. Verifying checks the signature against the correct key, proving the token was issued by a party who holds the signing secret and has not been altered since. Never trust claims from a decoded-but-unverified token in a security-sensitive context.
Why can this tool only verify HS256 tokens?
HS256 (HMAC-SHA256) is symmetric — the same secret both signs and verifies, so a client-side tool can check it with just the shared secret. RS256, ES256, and other asymmetric algorithms sign with a private key and verify with a public key; verifying those requires the issuer's public key (usually published at a JWKS endpoint), which this tool does not fetch. For asymmetric algorithms, use your backend JWT library or a tool that accepts a public key/JWKS URL.
What do the exp, iat, and nbf claims mean?
All three are Unix timestamps (seconds since epoch), per RFC 7519 §4.1: exp (expiration time) — the token must be rejected after this instant; iat (issued at) — when the token was created; nbf (not before) — the token must be rejected before this instant. This tool converts exp/iat/nbf to human-readable UTC dates automatically and flags an exp in the past as expired.
Is it safe to paste a real production JWT or secret into this tool?
Decoding and verification both run entirely in your browser via client-side JavaScript and the Web Crypto API — nothing you paste here, including the signing secret, is ever transmitted to any server. That said, treat any JWT holding real session data as a credential: if you're debugging a token from a shared or production environment, prefer a redacted copy or a locally-issued test token where practical.
Why does my token fail to decode?
The most common causes: the string isn't a JWT at all (JWTs always have exactly two dots — three segments); it was truncated when copied (check for a cut-off signature); or it's an encrypted JWE, not a signed JWS — JWEs have five segments instead of three and contain ciphertext, not a plain Base64URL-encoded JSON payload, so they cannot be decoded the same way.