JWT Decoder
Decode and inspect JSON Web Tokens instantly. View header algorithm, payload claims, expiry time, and signature structure — all client-side, nothing sent to server.
Decode JWT Token
Paste your JWT token below. Tokens are decoded entirely in your browser — your token is never sent anywhere.
What Is a JWT (JSON Web Token)?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined in RFC 7519. It is used to securely transmit information between parties as a JSON object. JWTs are the standard authentication mechanism for modern web applications, REST APIs, and single-page applications (SPAs). When a user logs in, the server creates a JWT containing the user's identity and permissions, signs it with a secret key, and sends it to the client. The client includes this token in subsequent API requests, allowing the server to verify the user's identity without querying a database on every request.
JWT Structure — Three Parts
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature
| Part | Contains | Example |
|---|---|---|
| Header | Algorithm (alg) and token type (typ) | {"alg": "HS256", "typ": "JWT"} |
| Payload | Claims — data about the user/entity | {"sub": "1234", "name": "Alice", "exp": 1704067200} |
| Signature | HMAC or RSA signature of header + payload | Verifies the token has not been tampered with |
The header and payload are simply Base64URL-encoded JSON — they are not encrypted. Anyone who has the token can decode and read the payload. The signature is what provides integrity: if a single character in the header or payload is changed, the signature verification will fail, and the server will reject the token.
Standard JWT Claims
| Claim | Full Name | Description |
|---|---|---|
sub | Subject | Who the token is about — typically the user ID |
iss | Issuer | Who created and signed the token (your auth server) |
aud | Audience | Intended recipient — prevents token reuse across services |
exp | Expiration Time | Unix timestamp after which the token is invalid |
iat | Issued At | Unix timestamp of when the token was created |
nbf | Not Before | Token is invalid before this Unix timestamp |
jti | JWT ID | Unique identifier to prevent token replay attacks |
Signing Algorithms
- HS256 (HMAC-SHA256): Symmetric — the same secret key signs and verifies the token. Simple and fast. Use when the same server that creates tokens also verifies them. The secret must be at least 256 bits (32 bytes) long for security.
- RS256 (RSA-SHA256): Asymmetric — a private key signs the token, and a public key verifies it. Use when different services need to verify tokens without having the private key (e.g., microservices architecture). The public key can be shared freely via JWKS endpoints.
- ES256 (ECDSA-SHA256): Asymmetric like RS256 but uses elliptic curve cryptography. Produces smaller signatures and is faster than RSA. Increasingly popular for mobile and IoT applications.
JWT Security Best Practices
- Never store secrets in the payload: The payload is Base64-encoded, not encrypted. Anyone can decode it. Do not put passwords, credit card numbers, or sensitive PII in JWT claims.
- Always validate the signature: Verify the token's signature on every request. Never trust the payload without verification — an attacker could craft a modified token with elevated permissions.
- Beware the "alg: none" attack: Some JWT libraries accept tokens with
"alg": "none"(no signature). Always configure your library to require a specific algorithm and reject unsigned tokens. - Set short expiration times: Access tokens should expire in 15–60 minutes. Use refresh tokens (stored securely, not in localStorage) to issue new access tokens. Short-lived tokens limit the window of abuse if a token is stolen.
- Store tokens securely: In browsers, store JWTs in HttpOnly, Secure, SameSite cookies — not in localStorage or sessionStorage, which are vulnerable to XSS attacks. In mobile apps, use the platform's secure keychain.
- Implement token revocation: JWTs are stateless — the server cannot "invalidate" a token before it expires. Implement a token blocklist or use short-lived tokens with refresh token rotation to handle logouts and compromised tokens.
JWT vs Session Cookies
Session cookies store a session ID in the cookie and keep the session data server-side (in memory, database, or Redis). The server looks up the session on every request. This approach is simpler to implement and easier to revoke (just delete the session), but requires server-side state and does not scale as easily across multiple servers.
JWTs are stateless — all the information is in the token itself. The server does not need to store session data, making JWTs ideal for microservices, mobile APIs, and horizontally scaled systems. The trade-off is more complex token management (expiration, refresh, revocation) and larger request headers.
Security Warning
Never paste production JWT tokens containing sensitive data into online tools you do not trust. This tool runs entirely in your browser — no data leaves your device. However, always treat JWTs like passwords: if a token is exposed, it can be used to impersonate the user until it expires.
Frequently Asked Questions — JWT Decoder
A JWT is a compact, URL-safe token used to securely transmit information between parties as a JSON object. It consists of three Base64URL-encoded parts separated by dots: Header (algorithm & token type), Payload (claims/data), and Signature (verification). JWTs are commonly used for authentication — once a user logs in, the server issues a JWT that the client sends with subsequent requests.
Yes — the header and payload are only Base64-encoded, not encrypted. Anyone with the JWT can decode and read the payload. Never store sensitive data (passwords, credit card numbers, SSNs) in a JWT payload. The signature verifies authenticity but does not hide the content. If you need encrypted tokens, use JWE (JSON Web Encryption) instead of plain JWT.
Decoding simply reads the header and payload — no secret needed. Signature verification checks that the token was issued by a trusted party and hasn't been tampered with, requiring the server's secret key (for HS256) or public key (for RS256). This tool decodes tokens for inspection purposes. Always verify signatures server-side before trusting token claims in production applications.
Standard registered claims: exp (expiration time — Unix timestamp after which the token is invalid), iat (issued at — when the token was created), nbf (not before — token not valid before this time), sub (subject — typically the user ID), iss (issuer — who created the token), aud (audience — intended recipients). These are conventions; any JSON data can be included in the payload.
The exp claim in the payload is a Unix timestamp. When the current time exceeds this value, the token is expired. JWTs typically expire in 15 minutes to 24 hours depending on the application's security requirements. Short-lived tokens reduce risk if stolen. Applications use refresh tokens (stored securely) to obtain new JWTs without requiring re-login.