JWT Deep Dive: Understanding and Debugging JSON Web Tokens

The Standard for Modern Auth

JSON Web Tokens (JWT) have become the de-facto standard for stateless authentication in APIs. Whether you are using Auth0, Firebase, or a custom-built solution, you are likely handling JWTs. But despite their popularity, they are often misunderstood, leading to critical security flaws. Our JWT Decoder allows you to peek inside these tokens while keeping your data 100% private.

The Three Parts of a JWT

Every JWT is composed of three strings separated by dots: the Header, the Payload, and the Signature. They are all Base64Url encoded (not encrypted!), which means anyone with the token can read the data. This is why you should never store sensitive info like passwords in a JWT.

Header: Usually contains the algorithm type (e.g., HS256 or RS256).
Payload: Contains "claims" like user ID (sub), issuer (iss), and expiration (exp).
Signature: The cryptographic proof that the payload hasn't been tampered with.

Debugging Claims and Expiration

One of the most common issues in web development is a mysterious '401 Unauthorized' error. Often, this is because the token has expired. Our decoder automatically converts the exp Unix timestamp into a human-readable date and highlights if it's in the past. If you're working with timestamps directly, you can also use our Timestamp Converter.

HS256 vs RS256

There are two main ways to sign a JWT:

Symmetric (HS256): Uses a single secret key to both sign and verify. Simple, but everyone who can verify can also sign.
Asymmetric (RS256): Uses a private key to sign and a public key to verify. This is much more secure for public-facing APIs.

Security Best Practices

Never trust a JWT without verifying its signature. Malicious users can easily modify the payload of an unverified token. Our tool supports both secret keys (HS256) and public keys (RS256) for on-the-fly verification. For generating secure secrets, we recommend using our Secure Password Generator.