JWT Decoder
Decode and inspect any JWT token. View header, payload, and signature in formatted JSON. Security analysis, expiration check, claims inspector — 100% client-side.
How JWT Tokens Work
A JWT (JSON Web Token) is made of three Base64url-encoded parts separated by dots: header.payload.signature. The header identifies the algorithm used to sign the token. The payload contains claims — data about the user or session. The signature proves the token was issued by a trusted party and has not been modified.
Anyone can decode the header and payload — they are only Base64url encoded, not encrypted. This is intentional: JWTs are designed for integrity (tamper-proof), not confidentiality. Never put sensitive secrets inside a JWT payload. The signature is the only cryptographic proof, and it can only be verified with the correct secret or public key.
JWT Security Best Practices
- Always verify the signature server-side. Decoding alone does not prove a token is valid — an attacker can craft any payload they want.
- Use asymmetric algorithms (RS256, ES256) for distributed systems. Symmetric HS256 requires sharing the same secret with every verifying service.
- Set short expiration times. Access tokens should expire in 15 minutes to 1 hour. Use refresh tokens for longer sessions.
- Always include iss (issuer) and aud (audience) claims. Without them, a token from one service can be replayed against another.
- Never use algorithm "none". Any server that accepts unsigned JWTs is critically vulnerable to forged authentication.
- Store tokens securely. Access tokens in memory; refresh tokens in HttpOnly cookies. Avoid localStorage for anything sensitive.
Frequently Asked Questions
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token used for authentication and information exchange between parties. It consists of three Base64url-encoded parts separated by dots: a header (algorithm and token type), a payload (claims/data about a user or session), and a signature (used to verify the token was not tampered with).
Is it safe to decode JWTs online?
This decoder is 100% client-side — your token is decoded using JavaScript running in your browser and is never transmitted to any server. For production tokens containing sensitive user data, always verify the tool is client-side before pasting. When in doubt, use a test or expired token for inspection.
What is the difference between JWT HS256 and RS256?
HS256 uses a single symmetric secret key for both signing and verification — whoever can verify a token can also forge one. RS256 uses an asymmetric key pair: a private key to sign, and a public key to verify. RS256 is generally more secure for distributed systems because the public key can be shared without exposing the signing capability. ES256 (ECDSA) is similar to RS256 but uses smaller keys and is increasingly common in modern systems.
What does "algorithm none" mean in a JWT?
An algorithm of "none" means the JWT has no signature — it is completely unsigned and trivially forgeable by anyone. A well-known JWT vulnerability involves downgrading the algorithm to "none" to bypass signature verification. Any server that accepts "none" JWTs is critically vulnerable. This decoder flags "none" as a critical security issue.
What are JWT claims?
Claims are the payload fields of a JWT — key/value pairs containing information about the subject (user). Standard registered claims include: sub (subject/user ID), iss (issuer), aud (audience), exp (expiration timestamp), iat (issued at), nbf (not before), and jti (unique token ID). Private claims are custom fields added by the application — like name, email, roles, or scope. This tool automatically recognizes all standard claims and displays human-readable descriptions.
Can this tool verify a JWT signature?
No. Verifying a JWT signature requires the secret key (for HS256) or the public key (for RS256/ES256), which are server-side secrets. This tool decodes the header and payload for inspection but cannot verify that the signature is valid. For production use, always verify tokens server-side using your auth library (e.g., jsonwebtoken in Node.js, PyJWT in Python, or jose in Go).
What should I check when debugging a JWT issue?
When debugging JWT issues: (1) Check the algorithm matches what your server expects. (2) Verify the exp claim — expired tokens are the most common cause of auth failures. (3) Confirm the iss (issuer) matches your auth provider. (4) Check the aud (audience) matches your API identifier. (5) Ensure the nbf (not before) claim is in the past. The Security Analysis section of this decoder flags all of these automatically.
What are refresh tokens vs access tokens?
Access tokens are short-lived JWTs (typically 15 minutes to 1 hour) used to authorize API requests. Refresh tokens are long-lived (days to weeks) opaque tokens used to get a new access token without re-authenticating. Refresh tokens are usually stored in an HttpOnly cookie (not accessible to JavaScript) to protect against XSS. Access tokens are typically stored in memory to protect against CSRF.