How to Decode a JWT (and Why You Should Never Paste One Online)

A JSON Web Token, or JWT, is the compact string an application hands you after you log in, which your browser then sends back to prove who you are. It looks like three chunks of gibberish separated by dots, but it is not random, each part is Base64url-encoded JSON that you can decode and read. The JWT Decoder unpacks one in your browser, and this article explains the structure, what the claims mean, and the crucial security reason to decode tokens locally rather than pasting them into a random website.

The headline safety point: a JWT usually identifies you to a system, so a valid token is like a temporary key to your account. Where you decode it matters enormously.

The three parts of a JWT

Every JWT has three sections separated by dots, and each is Base64url-encoded:

• Header: JSON describing the token type and the signing algorithm used, such as HS256 or RS256.
• Payload: JSON containing the claims: the actual data about who you are and what you can do.
• Signature: a cryptographic signature over the header and payload, used to verify the token has not been tampered with.

Because the first two parts are only encoded, not encrypted, anyone can decode and read them. The signature is what stops anyone from changing them without detection.

What the claims mean

The payload contains claims, many of which are standardised. You will commonly see sub (the subject, usually a user ID), iat (issued-at time), exp (expiry time), iss (issuer) and aud (audience). Alongside these, an application adds its own custom claims, a username, roles, permissions. Decoding a token to read these is the fastest way to answer questions like "why does this user see an admin menu?" or "has this token already expired?" The exp claim, a Unix timestamp, is especially useful for debugging authentication problems.

Signed versus encrypted, and what the signature proves

The signature is the security heart of a JWT. When a server issues a token, it signs the header and payload with a secret (for HMAC algorithms) or a private key (for RSA and elliptic-curve algorithms). When the token comes back, the server recomputes the signature and checks it matches. If someone edits the payload, say, changing their role from "user" to "admin", the signature no longer matches and the token is rejected. The signature therefore proves integrity and authenticity, but it does not provide confidentiality; for that you would need an encrypted token, which is a separate, less common construct.

Why you must not paste tokens into random sites

Here is the security crux. A live JWT is a bearer token: whoever holds it can act as you until it expires. Many online JWT decoders send the token to their server to decode it, which means you have just handed a working key to your account to an unknown third party. Even if they are honest, the token may sit in their logs. If it has not yet expired, that is a real account-takeover risk. The only safe way to inspect a token you care about is to decode it entirely on your own device.

A practical decoding workflow

When debugging authentication, decode the token to check three things first: is it expired (compare exp to the current time), who is it for (sub, aud), and what permissions does it carry (your custom claims). Because each part is just Base64url, you can even decode the pieces manually with a Base64 decoder if you want to see the mechanism, though a dedicated decoder is faster and handles the url-safe alphabet automatically.

Debugging authentication with a decoded token

Decoding a JWT is one of the most efficient ways to diagnose an authentication problem, because the token records exactly what the server believes about the session. When a user reports being unexpectedly logged out, decode their token and check the exp claim against the current time, an expired token is the most common culprit, and the timestamps make it obvious. When a user cannot access something they should, decode the token and inspect the role or permission claims: the answer is often that the token was issued before their permissions changed and simply has not been refreshed yet.

The claims also help when integrating with an identity provider. The iss and aud claims tell you which service issued the token and which service it is meant for, and a mismatch there explains many "invalid token" rejections. Because all of this information sits in the readable payload, decoding is usually faster than adding logging or stepping through code. The one rule that never bends: do this decoding locally. A token you are debugging is, by definition, a token that currently works, which makes it exactly the kind of credential you must never paste into a third-party site. A browser-based decoder gives you every claim you need while keeping the live token on your own machine.

Make local decoding a habit rather than an exception. The moment you paste a working token into a website to "just quickly check it," you have potentially handed over the keys to an account. A browser-based decoder removes that temptation entirely, giving you the full payload in a second without the token ever leaving your machine, which is exactly how inspecting a live credential should always work.

To recap: a JWT is three Base64url-encoded parts, a readable header and payload plus a signature that guarantees they have not been altered. It is signed, not secret, so never store confidential data in it, and never paste a live token into a website that decodes it server-side. Decode locally, read the claims, check the expiry, and the token stops being an opaque string and becomes a clear, debuggable record of a session.