JWT Decoder: Frequently Asked Questions

The ToolHive JWT decoder runs entirely in your browser — your token is never sent to any server. It is safe to use with tokens from development and staging environments. For production tokens containing sensitive user data, be cautious with any online tool, though the offline nature of this decoder means there is no network transmission.

No. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256/ES256), which only the server has. The decoder reads the payload and header without verifying the signature.

JWT payloads are base64url-encoded, not encrypted. This is by design — JWTs are meant to be readable by the recipient without needing a key. The signature only verifies that the payload has not been tampered with; it does not hide the content. Never put sensitive data in a JWT payload.

HS256 (HMAC-SHA256) uses a shared secret key — both the issuer and verifier know the same secret. RS256 (RSA-SHA256) uses a public/private key pair — the issuer signs with the private key, verifiers check with the public key. RS256 is preferred for APIs used by multiple clients because the private key never needs to be shared.

A JWT is a short-lived access token (typically 15 minutes to 1 hour) used to authenticate API requests. A refresh token is a longer-lived token (days to weeks) used only to obtain new JWTs when the current one expires. Refresh tokens are typically opaque strings (not JWTs) stored in the database.

The exp claim contains a Unix timestamp (seconds since January 1, 1970). When the current time passes this timestamp, the token is expired and servers should reject it. The decoder converts this timestamp to a human-readable date and flags expired tokens clearly.