JWT Decoder

Decode and inspect JWT tokens. View header, payload, and check expiration — all in your browser.

JWT decoding is for inspection and debugging purposes only. Never share JWTs containing real credentials or sensitive user data. Always verify JWT signatures server-side — this tool does not verify signatures.

Header


        

Payload


        

Signature (not verified)

Decoded Claims

⚠ This tool decodes the JWT client-side. The signature is NOT verified.

How It Works

Paste your JWT token into the input field. The tool splits the token at the dot separators and Base64-decodes the header and payload. It then displays each part as formatted JSON and checks the expiration claim automatically.

JWT (JSON Web Token) is a compact, URL-safe means of representing claims between two parties. JWTs are widely used in authentication systems — understanding how to decode and inspect them is essential for any web developer working with modern authentication.

**JWT Structure**

A JWT consists of three Base64URL-encoded parts separated by dots: `header.payload.signature`

- **Header**: Contains the token type ("JWT") and signing algorithm (e.g., HS256, RS256)
- **Payload**: Contains the claims — assertions about the user and metadata (subject, expiration, issued-at, custom claims)
- **Signature**: Cryptographically signs the header+payload to prevent tampering

**Reading JWT Claims**

Common payload claims include:
- `sub`: Subject — the user ID or entity the token is about
- `exp`: Expiration — Unix timestamp when the token expires
- `iat`: Issued At — when the token was created
- `nbf`: Not Before — token not valid before this time
- `iss`: Issuer — who issued the token
- `aud`: Audience — intended recipients

**What This Tool Does and Does Not Do**

This tool **decodes** the header and payload (which are merely Base64-encoded, not encrypted). It does **not** verify the signature — signature verification requires the secret key or public key and must be done server-side. Decoded payload data should not be trusted without verification.

**Security Considerations**

- Never store JWTs in localStorage for sensitive applications (use httpOnly cookies)
- Always check expiration (`exp` claim) server-side
- Never include sensitive data in JWT payload unless the token is encrypted (JWE)
- Use short expiration times for access tokens (15 minutes is common)

**Common JWT Issues**

- Token expired (`exp` in the past)
- Token not yet valid (`nbf` in the future)
- Wrong audience (`aud` mismatch)
- Algorithm mismatch (header says RS256 but server expects HS256)

**Privacy**

JWT decoding happens entirely in your browser. Never paste tokens containing real user credentials into third-party tools in production environments.

Frequently Asked Questions

A JSON Web Token (JWT) is a compact, URL-safe token that encodes claims as JSON. It is used for authentication and information exchange between parties.
No. Decoding reads the payload. Verification checks the cryptographic signature to ensure the token has not been tampered with. Always verify server-side.
Decoding runs in your browser. However, avoid pasting production tokens with real user credentials into any third-party tool. Use test or development tokens for debugging.
The payload is Base64URL-encoded. This tool automatically decodes it. If your token is encrypted (JWE), not just signed (JWS), the payload will not be readable without the decryption key.
The `exp` claim in the payload is a Unix timestamp. If that timestamp is in the past, the token has expired and should be rejected by the server.