JWT Tokens Explained: What's Actually Inside Them (and Why Decoding Isn't Verifying)

A JWT (JSON Web Token) looks like an opaque, encrypted string — three chunks of gibberish separated by dots. It isn't encrypted, and that distinction matters more than it might seem.

A JWT is encoded, not encrypted

A JWT has three parts — header, payload, and signature — and the first two are just Base64URL-encoded JSON, not encrypted data. Anyone who has the token, including a piece of client-side JavaScript or a browser extension, can decode the header and payload and read every field inside, instantly, with no key or password required. JWT Decoder does exactly that: split the token on its dots, Base64URL-decode the first two parts, and display the resulting JSON exactly as it decodes — no timestamp conversion, no highlighting of an expired token, just the raw decoded structure. This is the tool being precise about what decoding actually is, not a missing feature — the header and payload were never hidden in the first place.

The third part — the signature — is genuinely different: it's a cryptographic signature computed over the header and payload using a secret key (or a private key, for asymmetric algorithms) that only the issuing server holds. This decoder shows you the signature as raw text and does not verify it — verification requires the actual signing secret or public key, which the token itself never contains, and which a client-side tool has no legitimate way to obtain for someone else's token. Decoding tells you what a token claims; verifying tells you whether to trust that claim, and those are genuinely different operations requiring genuinely different information.

Why that distinction is a real security point, not trivia

Because the payload of a JWT is trivially readable by anyone holding the token, it should never contain anything sensitive on the assumption that "it's a token, not plain text" protects it — a password, a full credit card number, or similarly sensitive data embedded in a JWT payload is exposed to the same degree as if it were sitting in plain JSON. This is also exactly why pasting a real, live JWT (one currently valid for your own session on some service) into any online decoder — including this one — carries some risk if the tool were malicious: the decoded contents (user ID, roles, expiration) become visible to whatever's running that page. Using a tool that processes the token entirely in your browser, with nothing sent to a server, removes the "who else sees this" question, but it's still worth treating a real token with the same caution you'd apply to any other credential.

The building blocks underneath

A JWT's Base64URL encoding is a variant of the same encoding Base64 Encoder & Decoder works with — the difference is JWTs substitute - and _ for the + and / characters standard Base64 uses, specifically so the result is safe to put in a URL without additional escaping. If you ever need to manually inspect or reconstruct a token's parts, understanding that relationship is more useful than treating JWT decoding as an unrelated black box.

Related but distinct: if what you're actually encoding is a value going into a URL's query string — not a JWT — that's URL Encoder & Decoder's job, using percent-encoding rather than Base64. And if you're generating unique identifiers for session tokens, request IDs, or database keys rather than decoding existing ones, UUID v4 Generator calls the browser's native crypto.randomUUID() for a cryptographically random ID, entirely client-side.

The Bottom Line

A JWT reveals its contents to anyone who has it — that's how the format works, not a flaw in a particular decoder. The signature is what actually protects a JWT from tampering, and checking that signature is a fundamentally different, server-side operation from reading the payload. Knowing the difference between "I can see what this token says" and "I've confirmed this token is genuine" is the actual security-relevant takeaway, well beyond just this one tool.