JWT Decoder

JWT (JSON Web Token, RFC 7519) is a compact, URL-safe means of representing claims to be transferred between two parties. It's commonly used for authentication and authorization in web applications. Structure: JWTs consist of three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded. Header (algorithm & token type): {"alg":"HS256","typ":"JWT"}—specifies the signing algorithm (HS256, RS256, ES256, etc.) and token type. Payload (claims): contains statements about an entity (typically the user) and additional metadata. Standard claims include: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration time), nbf (not before), iat (issued at), jti (JWT ID). Signature: used to verify the message wasn't changed along the way. For HMAC algorithms, secret = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). For RSA/ECDSA, sign with private key, verify with public key. Our decoder parses all three parts, validates Base64URL encoding, checks expiration claims, and displays the content in a human-readable format. Common use case: After user logs in, server creates JWT with user ID and claims, client stores JWT (localStorage/cookie), client sends JWT in Authorization header for subsequent requests, server validates signature and extracts claims.

Yes, decoding JWTs is safe because JWTs are not encrypted—they're encoded, not encrypted. Anyone who possesses a JWT can read its payload simply by Base64-decoding it. Our tool adds safety: all decoding happens locally in your browser using client-side JavaScript, your tokens are never sent to any server, no data leaves your device, tool works offline after initial page load, HTTPS ensures the tool itself hasn't been tampered with. Security best practices: never share tokens containing sensitive information via untrusted channels, be cautious when pasting tokens with PII (personally identifiable information) or secrets, remember that the payload is readable by anyone—don't store sensitive data in JWT claims, use HTTPS always when transmitting tokens, validate tokens server-side even if client checks expiration, implement short expiration times (15-30 minutes for access tokens), use refresh tokens for long-term sessions, never include passwords or API secrets in JWT payloads. Our tool is safe for debugging and development but consider using offline tools for production tokens with highly sensitive data.

JWT supports multiple signing algorithms with different security properties: HS256 (HMAC with SHA-256)—symmetric, shared secret, fastest, simplest, best for: service-to-service communication, internal microservices, cases where you control both parties. HS384/HS512—stronger HMAC variants, rarely needed, SHA-384/SHA-512 instead of SHA-256. RS256 (RSA Signature with SHA-256)—asymmetric, public/private key, best for: third-party authentication, identity providers (Auth0, Firebase, Okta), scenarios where token issuer and verifier are different parties. RS384/RS512—stronger RSA variants, larger signatures, slower verification. ES256 (ECDSA using P-256 and SHA-256)—asymmetric, smaller signatures than RSA, best for: mobile apps (smaller token size), IoT devices with limited bandwidth, environments where signature size matters. EdDSA (Ed25519 signature)—modern, fast, secure, small signatures, increasingly recommended over ECDSA. none (unsigned)—DANGEROUS, never use in production,任何人can forge tokens. Recommendation: Use HS256 for simple apps with trusted parties. Use RS256 or ES256 for public-facing applications with third-party access. Avoid 'none' algorithm entirely. Our decoder identifies the algorithm and warns if 'none' is detected.

JWT expiration (exp claim) is critical for security. Our decoder shows: expiration timestamp in both Unix epoch and human-readable format, time until expiration (e.g., 'expires in 5 minutes'), expired status if current time > exp. Best practices for token lifecycle: Access tokens—short-lived (15-30 minutes), contain minimal claims, used for API authentication. Refresh tokens—long-lived (days/weeks), stored securely (httpOnly cookie), used to obtain new access tokens, can be revoked. Rotation strategies: automatic refresh before expiration (when 75% of lifetime elapsed), silent refresh in background, force reauthentication if refresh token expires. Implementation flow: 1) User authenticates with credentials, 2) Server issues access token (15 min) + refresh token (7 days), 3) Client uses access token for API calls, 4) Before access token expires, client uses refresh token to get new access token, 5) If refresh token expires, user must re-authenticate. Security considerations: store tokens securely (httpOnly cookies preferred over localStorage), implement token revocation for logout, detect token theft by monitoring usage patterns, use short expiration to limit damage from leaked tokens. Our tool helps debug expiration issues by showing exact timestamps.