JWT Decoder

These refer to the signing algorithm in the JWT header. HS256 (HMAC-SHA256) uses a shared secret — the same key is used to sign and to verify. This means anyone with the key can also create valid tokens. RS256 (RSA-SHA256) uses a public/private key pair — the server signs with a private key and publishes a public key for verification. RS256 is more secure in distributed systems because verifiers only need the public key and cannot forge tokens. This decoder shows you the alg field but cannot verify either algorithm — it only reads what is inside.

No. Signature verification requires the secret (for HMAC algorithms) or public key (for RSA/EC algorithms) that was used to sign the token. This tool only decodes — it Base64url-decodes the header and payload to show you the content without any cryptographic verification. The signature section is displayed as-is but not validated. For signature verification, use your server-side JWT library (jsonwebtoken for Node.js, PyJWT for Python, java-jwt for Java, etc.).

Registered claims are standardized payload fields defined in RFC 7519. The seven standard claims: iss (issuer) — who issued the token; sub (subject) — who the token is about (usually a user ID); aud (audience) — intended recipients; exp (expiration time) — Unix timestamp after which the token is invalid; nbf (not before) — Unix timestamp before which the token should not be accepted; iat (issued at) — Unix timestamp when the token was created; jti (JWT ID) — unique identifier for the token. This tool converts exp, nbf, and iat from Unix timestamps to human-readable dates.

The decoder checks the exp claim against the current time and clearly marks expired tokens. An expired token means the API will reject it with a 401 Unauthorized response — you need to use your refresh token to get a new access token (if your auth system supports refresh tokens) or log in again. If you are debugging an "expired token" error from an API, this decoder will show you exactly when the token expired and when it was issued.

The alg field in the header is displayed as decoded — if a token has "alg":"none" you will see it. This is a known JWT vulnerability: some early implementations accepted tokens with no signature (alg:none), allowing attackers to forge arbitrary payloads. Any properly implemented JWT library rejects alg:none tokens by default. If you see alg:none in a token from your own system, that is a critical security bug that needs immediate attention.

No. All decoding happens in your browser using JavaScript — Base64url decoding requires no server-side computation. Your JWT tokens, including any user IDs, roles, or session data they contain, never leave your device. That said, be cautious about pasting production JWT tokens into any online tool — even this one. For debugging production auth issues, use your browser's developer tools network tab or your logging system instead.

A valid JWT must have exactly two dots separating three Base64url-encoded sections. If a token has no dots, it is not a JWT — it may be an opaque token (a random identifier that requires a server-side lookup) rather than a self-contained JWT. Some systems use both types: an opaque refresh token and a JWT access token. If you receive an "Invalid JWT format" error, verify you are pasting the access token (which should start with "ey") and not the refresh token.