What Is a JWT and How to Decode One Safely

A JWT ("JSON Web Token") is the compact, three-part string you'll see in an Authorization header, a session cookie, or an API response — something like eyJhbGciOi...eyJzdWIiOi...SflKxwRJ.... It looks encrypted. It isn't. Here's what's actually inside one, and how to look without accidentally leaking a secret.

Steps

1. Open JWT Decoder and paste the full token.
2. Run it — the header and payload are decoded and shown as readable JSON immediately.
3. Read the claims. The signature itself is not verified, since that needs the secret key, which this tool never asks for.

What's actually in the three parts

A JWT is three Base64URL-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (commonly HS256 or RS256). The payload holds the actual claims — often things like sub (subject/user id), exp (expiry timestamp), and whatever custom fields the issuing service added. Both are just Base64URL-encoded JSON — no encryption, no key required to read them. Anyone who has the token can read its contents, which is exactly why a JWT should never be used to hold anything actually secret (a password, a credit card number); it's a signed claim, not a locked box.

Decoding vs. verifying — the distinction that matters

Decoding just reveals what a token claims. Verifying confirms the signature was produced by the real secret key, which is what actually proves the token hasn't been tampered with. A decoder that asked for your signing secret to "verify" a token pasted from production would be asking you to hand over the one thing that lets anyone forge new tokens — worth being suspicious of any tool that does. This one deliberately doesn't: it decodes, states plainly that the signature isn't verified, and stops there.

Building and signing a new token instead of inspecting an existing one? That's a different tool — see JWT Encoder, which does ask for a secret, because signing genuinely requires one.