JWT Token Explained – Decode, Validate and Understand JWT Easily

Your API request comes back with a 401. The error says TokenExpiredError — but you deployed five minutes ago and the token looks fine. Or worse: invalid signature, with no indication of which key is wrong or why. A JWT decoder online lets you paste the token and immediately see the decoded payload, the exact expiry timestamp, and the algorithm — no code required.

At some point in almost every web project, you will encounter a JWT. It might be the value sitting in your Authorization header, the token your frontend stores in localStorage, or the access_token field in an OAuth response. They all look the same: three blocks of characters separated by dots, completely opaque until you know what you are looking at. This post breaks down the JWT token in plain terms — what the three parts mean, how authentication systems use them, what can go wrong, and how to decode and inspect one without writing any code.

# A JWT has three dot-separated parts:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9        ← Header  (Base64URL-encoded JSON)
.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTcwMDA0MH0 ← Payload (Base64URL-encoded claims)
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← Signature (server-verified)

# Decoded payload — readable by anyone with the token:
{
  "sub": "user_123",
  "iat": 1700000000,   ← issued at (Unix timestamp)
  "exp": 1700036000,   ← expiry  — TokenExpiredError if now > this
  "role": "admin"
}

What Is a JWT?

JWT stands for JSON Web Token, defined in RFC 7519. It is a compact, URL-safe string that encodes a JSON object and — optionally — proves that the object has not been tampered with. Every JWT is made up of three Base64URL-encoded parts joined by dots: Header.Payload.Signature.

The Header

The header is a small JSON object that declares the signing algorithm and token type. The alg field matters: HS256 means HMAC-SHA256 with a shared secret; RS256 means RSA with a private/public key pair.

The Payload

The payload contains claims — key-value pairs about the user or token. Standardized claims include sub (subject), iat (issued at), exp (expiry), and nbf (not before). The payload is encoded, not encrypted — anyone who has the token can read it.

The Signature

The signature is computed from the encoded header and payload using the signing key. When a server receives a token, it recomputes the signature and compares it. If someone modifies the payload, the signature will not match and the token will be rejected.

Why Developers Use JWT

JWTs are stateless. A traditional session system requires the server to store and look up session data on every request. With JWTs, the server encodes everything it needs into the token, signs it, and hands it to the client. Subsequent requests are verified by signature check alone — no database lookup required.

This makes JWTs well-suited for distributed systems. Any service with the signing key can independently verify a token, which is why they are the standard format in OAuth 2.0 and OpenID Connect.

JWT payloads often contain Base64URL-encoded data — see our guide on Base64 encoding and decoding to understand how the encoding works. If your auth flow also returns JSON API responses, our JSON formatter guide covers how to inspect and debug those payloads.

The exp claim is a Unix timestamp. Use the Timestamp Converter to quickly check when a token expires.

How to Decode and Validate a JWT

Decoding and validating are different operations. Decoding means reading the header and payload — anyone can do this without the signing key. Validating means verifying the signature and checking claims — this requires the secret or public key.

1. Split the token on . — you get three segments.
2. Base64URL-decode the first segment to get the header JSON.
3. Base64URL-decode the second segment to get the payload JSON.
4. Check exp against the current Unix timestamp to confirm the token has not expired.

For production validation, always do it server-side using a library. Never trust client-provided claims without server verification. To quickly inspect a token during development, paste it into the DevToolBox JWT Decoder. DevToolBox tools run entirely in your browser — no signup, no data sent to a server.

Common JWT Mistakes

• Expired token. If the current time is past the exp value, the token is invalid regardless of whether the signature is correct. Decode the token and check the exp timestamp — this is the most common cause of unexpected 401s.
• Invalid or mismatched signature. Happens when a token is verified against the wrong secret, or when staging tokens are presented to a production service with a different signing key. Decoding the header reveals the algorithm; confirming it matches what your server expects is the first debugging step.
• Algorithm confusion. Some older libraries accept whatever algorithm the header claims, including none. Always pin the expected algorithm on the server side.
• Storing JWTs in localStorage. Tokens there are accessible to any JavaScript on the page, making them vulnerable to XSS. HttpOnly cookies are generally safer.

Never put sensitive data (passwords, payment info) in the JWT payload. It is encoded, not encrypted — anyone with the token can read it.

Frequently Asked Questions

Conclusion

JWTs follow a simple structure: a header declaring the algorithm, a payload carrying the claims, and a signature tying them together. Once you know how to read the three parts, debugging auth issues — expired tokens, mismatched signatures, wrong algorithms — becomes significantly more straightforward.

If you need a fast JWT decoder online that shows the decoded header, payload, and an expiry check in one click, DevToolBox does exactly that. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.