JWT Decoder — Decode & Inspect JSON Web Tokens Free

Paste a JWT token to instantly decode its header, payload, and signature. Check expiration, inspect claims, and understand token structure — all in your browser, no signup needed.

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is a compact, URL-safe string that represents claims between two parties. Defined by RFC 7519, a JWT consists of three Base64url-encoded parts separated by dots: a header specifying the algorithm and token type, a payload containing the claims (user data, permissions, expiration), and a signature ensuring the token hasn't been tampered with.

JWTs are the backbone of modern authentication. OAuth 2.0, OpenID Connect, and most API authentication systems use JWTs to pass identity and authorization data between services. Unlike session cookies, JWTs are stateless — the server doesn't need to store session data, making them ideal for microservices and distributed architectures.

How to Decode a JWT

Decoding a JWT is straightforward because the header and payload are simply Base64url-encoded JSON — not encrypted. Paste any token starting with eyJ into the input field and the decoder instantly splits it into its three parts. The header reveals the signing algorithm (HS256, RS256, etc.) and token type. The payload shows all claims with timestamps automatically converted to human-readable dates and relative time. Special claims like exp, iat, and sub are labeled for quick understanding.

Remember: decoding is not the same as verifying. Anyone can read a JWT's contents without the secret key. The signature exists to prove the token wasn't modified, but verifying it requires the signing key and is typically done server-side.

Understanding JWT Claims

JWT claims are the key-value pairs in the payload. The specification defines seven registered claims: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID). Beyond these, applications add custom claims for roles, permissions, email, and other user attributes. This decoder highlights registered claims with labels and timestamps while distinguishing custom claims visually.

JWT Security Best Practices

Always set short expiration times (exp) and use refresh tokens for long-lived sessions. Never store sensitive data in the payload since it is only encoded, not encrypted. Validate the alg header server-side to prevent algorithm confusion attacks. Use RS256 over HS256 when the token is verified by multiple services. Store JWTs in httpOnly cookies rather than localStorage to mitigate XSS attacks. Always reject tokens with alg: "none" in production.

Related Tools

JSON Formatter

Format and validate JSON

Base64 Encoder/Decoder

Encode and decode Base64

Hash Generator

Generate MD5, SHA hashes

JSON Viewer

Explore JSON with tree view

Frequently Asked Questions

Does this tool verify JWT signatures?+
No. This tool decodes and inspects the structure of a JWT but does not verify its cryptographic signature. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). The signature section shows the raw signature data and notes this distinction.
Is it safe to paste my JWT token here?+
Yes. All decoding happens entirely in your browser using JavaScript. No data is sent to any server, stored, or logged. Your token never leaves your device. That said, JWTs often contain sensitive claims, so avoid sharing them in public channels regardless of the tool you use.
How does the tool check if a token is expired?+
The decoder reads the 'exp' (expiration) claim from the payload, converts the Unix timestamp to a human-readable date, and compares it to the current time. If the current time is past the expiration, the token is flagged as expired with a red badge showing how long ago it expired.
What is the difference between HS256 and RS256?+
HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification, making it simpler but requiring the secret to be shared. RS256 (RSA-SHA256) uses an asymmetric key pair: a private key signs the token and a public key verifies it. RS256 is preferred for distributed systems where you don't want to share a secret.
What is the alg:none vulnerability?+
Some JWT libraries accept tokens with 'alg' set to 'none', meaning no signature verification is performed. An attacker can forge a token by setting alg to none and removing the signature. Modern libraries reject alg:none by default, but it remains a critical security consideration when implementing JWT verification.

Last updated: March 2026