JWT (JSON Web Token) is a compact, URL-safe token format used for authentication and information exchange. It consists of three parts separated by dots: Header.Payload.Signature. The signature is created by applying a cryptographic algorithm (HMAC, RSA, or ECDSA) to the header and payload using a secret key or private key. Verification confirms the token hasn't been tampered with and was issued by a trusted party.

HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification — ideal for simple systems.
RS256 (RSA-SHA256) uses a private key to sign and a public key to verify — perfect for distributed systems where only the issuer signs tokens.
ES256 (ECDSA-P256-SHA256) uses elliptic curve cryptography, offering smaller key sizes and faster operations compared to RSA at similar security levels. Choose based on your architecture: HS256 for monolithic apps, RS256/ES256 for microservices and third-party verification.

Yes — this tool runs entirely in your browser. No data is ever sent to any server. All parsing, decoding, and cryptographic verification happens locally using the Web Crypto API. Your JWT tokens and keys never leave your device. However, always exercise caution: never paste production tokens on shared computers, and clear your clipboard after use.

For RSA (RS256/RS384/RS512/PS256/PS384/PS512) and EC (ES256/ES384/ES512) algorithms, you need the public key in PEM format. The key should start with -----BEGIN PUBLIC KEY----- and end with -----END PUBLIC KEY-----. This is the standard SPKI (SubjectPublicKeyInfo) format. For HMAC algorithms, simply provide the raw shared secret string.

Common reasons include: (1) Algorithm mismatch — the JWT header's alg must match your key type. (2) Using the wrong key — HMAC requires the exact shared secret; RSA/EC require the correct public key. (3) The token was modified after signing. (4) Extra whitespace or encoding issues in the key. (5) Using a private key instead of a public key for RSA/EC verification, or vice versa.

No. JWT signs data to ensure integrity and authenticity, but it does not encrypt the payload. The header and payload are only base64url-encoded — anyone can decode and read them. Never store sensitive information (passwords, credit card numbers, PII) in a JWT payload unless you use JWE (JSON Web Encryption), which is a separate standard. Always transmit JWTs over HTTPS.

Look at the exp (expiration time) claim in the decoded payload. It's a Unix timestamp (seconds since epoch). If the current time is past this value, the token has expired. Similarly, iat (issued at) tells you when the token was created, and nbf (not before) indicates when the token becomes valid. This tool automatically highlights expired tokens with a warning indicator.

JWT uses base64url encoding, a URL-safe variant of standard base64. The differences: + is replaced with -, / is replaced with _, and trailing = padding characters are omitted. This ensures JWT tokens can be safely used in URLs and query parameters without additional encoding.

Yes — the algorithm is specified in the JWT header under the alg field. This tool automatically extracts and displays it. However, in production systems, you should never blindly trust the header's alg value without validation, as this can lead to algorithm confusion attacks. Always maintain an allowlist of accepted algorithms on your server.

PS256/PS384/PS512 use RSA-PSS (Probabilistic Signature Scheme) instead of the traditional PKCS#1 v1.5 padding used by RS256/RS384/RS512. RSA-PSS is considered more secure because it includes random salt in the signature, making it non-deterministic. Each PS256 signature of the same data will be different, while RS256 always produces the same signature for identical inputs. Both use RSA keys but differ in the padding scheme.