JWT Tokens Explained: Structure, Security and How to Decode Them

If you have logged into a modern web application, you have almost certainly held a JWT — a JSON Web Token — in your browser's memory. It is the standard way apps pass identity and permissions to an API: log in once, receive a token, and attach it to every subsequent request. Developers debug these tokens constantly, which is where JWT decoding tools come in. This guide explains how they work and — crucially — how to inspect one safely.

Anatomy of a JWT

A JWT is a compact, URL-safe string with three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwibmFtZSI6IkFsaWNlIn0.kXsd_SxZVkTo6bvLYJvMjNY_2dU-h59DtiQ4kB-dq7I

• Header (first part): the algorithm used, usually HS256 (symmetric) or RS256 (asymmetric).
• Payload (second part): the claims — user ID, roles, expiry (exp), issued-at (iat).
• Signature (third part): a cryptographic hash over header + payload that only the server can verify.

Each part is Base64Url-encoded JSON. That means the header and payload are readable by anyone who decodes them — they are not encrypted. Only the signature is secret. This is the single most important thing to understand about JWTs: a token's middle section is plain text; anyone holding the token can read your claims.

Decoding is not verifying

A decoder shows you the claims; only signature verification proves the token wasn't forged. When you decode a token in a tool you are inspecting the payload, not confirming it is valid.

Security: never paste a live token into unknown sites

A bearer token is the key to your account session. Pasting it into an online decoder sends that key to a stranger's server — and because the payload is trivial to decode, the 'service' gains nothing they couldn't get locally, while you lose the only thing worth protecting. Treat tokens like passwords: they belong in local tooling only.

• Prefer decoders that run entirely in the browser, with no network request.
• Generate a fake or expired token and decode that for practice instead of a live one.
• Revoke tokens if you suspect one was exposed — most auth systems let you invalidate a session.

What to look for when you decode

• exp (expiration): is the token still within its validity window?
• iat (issued at): when was it created?
• sub (subject): which user does it identify?
• roles/scopes : what is the token permitted to do?
• iss/aud (issuer/audience): was it meant for this service?

Diagnosing a 401, debugging an authorization flow, or explaining a token to a teammate all start with a clean decode — done locally, in seconds.

JWT decoding in Convrs

Convrs includes a JWT decoder that runs entirely in the browser. You paste a token, the three parts are Base64Url-decoded client-side, and you see the header and payload as readable JSON. No request is made to any server, so even a production token stays on your machine.