What are the three parts of a JWT?

A JWT consists of three parts separated by dots (`.`): 1) The Header (Base64URL encoded JSON) specifying the algorithm (e.g., HS256). 2) The Payload (Base64URL encoded JSON) containing the 'claims' (e.g., user ID). 3) The Signature (a hash) used to verify the token hasn't been tampered with.

Is the JWT payload encrypted?

No. This is a critical misconception. The payload is not encrypted , it is only Base64URL encoded . Anyone can decode it. Therefore, you must never put sensitive secrets (like a password) in the payload. A JWT provides authentication (proof of origin), not confidentiality (secrecy).

What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) is symmetric . The same secret key is used to both create and verify the signature. RS256 (RSA-SHA256) is asymmetric . A private key creates the signature, and a public key (which can be shared) verifies it. RS256 is generally more secure for public-facing applications.

JWT Debugger & Decoder

Decode, verify, and inspect JSON Web Tokens (JWT) in real-time.

100% Client-Side & Secure

All JWT decoding and verification happens in your browser.
Your tokens, secrets, or keys are never stored or sent to our servers.
It's safe to use with your production tokens.

What is a JWT (JSON Web Token)? A Deep Dive

A JSON Web Token (JWT) is a compact, URL-safe standard (RFC 7519) used to securely transmit information ("claims") between parties as a JSON object. It is the most common method for handling stateless authentication and authorization in modern web applications and APIs.

A JWT is not a random string. It is a Base64URL-encoded string with three parts separated by dots (.):

HEADER.PAYLOAD.SIGNATURE

Header (Base64URL): A JSON object that describes the token, including the token type (typ: "JWT") and the signing algorithm used (alg: "HS256" or "RS256").
Payload (Base64URL): A JSON object containing the "claims"—statements about an entity (typically the user) and additional data. This is where you find user ID (sub), name (name), and issue/expiration times (iat, exp).
Signature: This is the security. To create the signature, you hash the encoded header, the encoded payload, and a secret key (for HS256) or a private key (for RS256).

CRITICAL: The Payload is ENCODED, Not ENCRYPTED.
Anyone can decode the Header and Payload of a JWT. This debugger does just that. Never put sensitive information (like passwords) in the payload. The signature's only job is to verify that the Header and Payload have not been tampered with by an attacker.

JWT Examples

Loading JWT examples...

JWT Best Practices & Key Concepts

🚫

Payload is NOT Encrypted

The biggest mistake is assuming the JWT payload is secret. It is only Base64 encoded and is publicly readable. Never store user passwords, API keys, or other sensitive secrets in the payload. JWTs provide authentication (who you are), not confidentiality (secrecy).

⚖️

HS256 vs. RS256

HS256 (Symmetric): Uses one secret key to both sign and verify. Fast and simple. The server and client must share the same secret.
RS256 (Asymmetric): Uses a private key to sign and a public key to verify. More complex, but more secure, as the private key never leaves the server.

✅

Always Verify the Signature

A JWT is just a piece of text. Never trust the data inside the payload (e.g., {"admin": true}) until you have cryptographically verified the signature. If the signature is invalid or the alg is "none", the token is untrusted and must be rejected immediately.