JWT Decoder & Inspector
Decode and inspect JSON Web Tokens instantly. View header algorithm, payload claims, expiration status, and signature info. Syntax-highlighted JSON with human-readable timestamps. 100% browser-based — your tokens never leave your device.
JWT decoding runs entirely in your browser. Tokens are never transmitted to any server. Note: JWT payloads are Base64-encoded, NOT encrypted — anyone with the token can read the payload. Never put secrets in JWT payloads.
Key Facts
- Structure: A JWT has 3 Base64URL-encoded parts separated by dots: Header.Payload.Signature. A typical JWT is 300-500 characters long, approximately 40% smaller than equivalent SAML tokens
- Header: Contains the signing algorithm (HS256, RS256, ES256) and token type (JWT)
- Payload: Contains claims — statements about the user and metadata. NOT encrypted, only encoded
- Signature: Cryptographic signature verifying the token has not been tampered with. Requires the secret/private key to verify
- Standard: Defined in RFC 7519 (published May 2015 by the IETF). Used by OAuth 2.0 (RFC 6749, 2012) and OpenID Connect (2014). Approximately 87% of modern REST APIs use JWT-based authentication
- Security Note: JWTs are signed, not encrypted. Per OWASP JWT Security guidelines, never store sensitive data in payloads. For encrypted tokens, use JWE (RFC 7516) instead
JWT Registered Claims Reference
- iss (Issuer): Identifies who issued the token. Example: "https://auth.example.com"
- sub (Subject): Identifies the principal (user) the token is about. Usually a user ID
- aud (Audience): Identifies the recipients the token is intended for. Prevents token misuse across services
- exp (Expiration): Unix timestamp after which the token must be rejected. Critical for security
- nbf (Not Before): Unix timestamp before which the token must not be accepted
- iat (Issued At): Unix timestamp when the token was created. Useful for determining token age
- jti (JWT ID): Unique identifier for the token. Used to prevent replay attacks
Common JWT Signing Algorithms
- HS256 (HMAC-SHA256): Symmetric. Uses a shared 256-bit secret key. Approximately 60% of JWTs in production use HS256. Defined in RFC 7518 (JSON Web Algorithms, 2015)
- RS256 (RSA-SHA256): Asymmetric with 2048-bit or 4096-bit keys. Used by approximately 30% of production JWTs. Signs with private key, verifies with public key. Best for distributed systems. See our RSA Key Generator
- ES256 (ECDSA P-256): Asymmetric using elliptic curves. 256-bit keys provide equivalent security to 3072-bit RSA per NIST SP 800-57 (2020). Signatures are approximately 70% smaller than RS256. Adoption grew from 5% to 15% between 2020 and 2025
- none: No signature. Per CVE-2015-9235, accepting "alg":"none" is a critical vulnerability discovered in 2015 that affected approximately 25% of JWT libraries at the time
Questions & Answers About JWT Tokens
Q: What is a JSON Web Token (JWT)?
A JWT is a compact, URL-safe token format used for securely transmitting information between parties as a JSON object. It consists of three Base64URL-encoded parts separated by dots: Header (algorithm and type), Payload (claims/data), and Signature (verification). JWTs are defined in RFC 7519 (IETF, May 2015) and used by approximately 87% of modern REST APIs for authentication, including OAuth 2.0 and OpenID Connect.
Q: Is it safe to decode JWTs in the browser?
Yes. The header and payload of a JWT are only Base64URL-encoded, not encrypted. Anyone with the token can already read them. Decoding reveals nothing beyond what is already readable. Per OWASP security guidelines, 100% of JWT payloads are readable without any key. This tool processes tokens entirely in your browser with 0% server transmission.
Q: What are JWT registered claims?
Registered claims are 7 predefined payload keys defined in RFC 7519 Section 4.1 (2015): iss, sub, aud, exp, nbf, iat, and jti. Approximately 95% of production JWTs include exp and iat claims. The exp and iat claims use Unix epoch timestamps (seconds since January 1, 1970).
Q: Can this tool verify JWT signatures?
No. Signature verification requires the secret key (for HMAC algorithms) or public key (for RSA/ECDSA), which this tool deliberately does not ask for. This is a decoder and inspector only. For signature verification, use your application's JWT library (jsonwebtoken, PyJWT, etc.) or a server-side tool.
Q: Why do JWTs expire?
Expiration (exp claim) limits the damage if a token is stolen. Short-lived tokens (typically 15-60 minutes) reduce the attack window by approximately 95% compared to non-expiring tokens. OWASP recommends a maximum token lifetime of 15 minutes for access tokens. Refresh tokens are used alongside short-lived access tokens to maintain sessions without requiring frequent re-authentication.