JWT Decoder — Inspect JSON Web Tokens

A JWT is a compact, URL-safe token format defined by RFC 7519 for securely transmitting information between parties. It consists of three base64url-encoded parts separated by dots: the Header (specifies the signing algorithm and token type), the Payload (contains claims — data like user ID, roles, and expiration time), and the Signature (cryptographic proof that the token has not been tampered with). JWTs are the standard for authentication and authorization in modern web applications and APIs.

Yes, decoding a JWT is completely safe. Decoding simply means base64url-decoding the header and payload — it does not require or expose the secret key used for signing. The JWT payload is not encrypted, just encoded, so anyone with the token can read the claims. Our tool runs entirely in your browser with zero server requests, so your tokens are never transmitted anywhere. That said, never share JWTs publicly or in URLs, as they contain user data and grant access until they expire.

This tool decodes and displays JWTs but does not perform signature verification. Verifying a signature requires the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256 or ES256). For server-side signature verification, use libraries like jsonwebtoken (Node.js), PyJWT (Python), jwt-go (Go), or nimbus-jose-jwt (Java).

Standard registered claims include: "sub" (subject — typically the user ID), "iss" (issuer — the service that created the token), "aud" (audience — the intended recipient service), "exp" (expiration time as a Unix timestamp), "iat" (issued at — when the token was created), "nbf" (not before — the token is invalid before this time), and "jti" (JWT ID — a unique identifier for the token). Applications commonly add custom claims like "role", "email", "permissions", "org_id", and "scope".

The "exp" claim contains a Unix timestamp (seconds since January 1, 1970 UTC). If this timestamp is in the past relative to your current system clock, the token is expired. Common causes include: the token lifetime being too short (e.g., 5 minutes), clock skew between the issuing server and your machine, the token being issued a long time ago without refresh, or timezone misconfiguration. Compare the "iat" and "exp" claims to understand the intended token lifetime.

HS256 (HMAC-SHA256) uses a shared secret key for both signing and verification — simpler but requires the secret to be shared with all verifiers. RS256 (RSA-SHA256) uses an asymmetric key pair: the private key signs and the public key verifies — ideal for distributed systems where verifiers should not have the signing key. ES256 (ECDSA-SHA256) also uses asymmetric keys but with elliptic curve cryptography, producing smaller signatures than RSA with comparable security.

Yes. JWTs follow the RFC 7519 standard, so this tool works with tokens from any provider: Auth0, Firebase Authentication, AWS Cognito, Okta, Azure AD, Google Identity, Keycloak, Supabase, and any custom JWT implementation. The decoded header and payload structure will vary based on the provider, but the three-part format is universal.

Avoid putting sensitive information in JWT payloads because they are only base64-encoded, not encrypted. Never include passwords, credit card numbers, API secret keys, or personally identifiable information (PII) beyond what is strictly necessary. Keep tokens lean — include only the claims needed for authorization decisions (user ID, roles, expiration). For sensitive data, use encrypted JWTs (JWE) or keep the data server-side and reference it by ID.

Common causes of invalid token errors: the string is not a valid JWT (it must have exactly three dot-separated segments), the base64url encoding is corrupted (often happens when tokens are truncated in logs or URLs), or extra whitespace and newline characters were included when pasting. Make sure you copy the complete token string including all three parts.