How to Decode a JWT Safely in Your Browser
June 2, 2026 · 3 min read
JSON Web Tokens (JWTs) are everywhere in modern auth — they're what your app hands back after login, and what your API checks on every request. When something goes wrong with authentication, the first debugging step is usually to decode the token and read what's inside. This guide explains how JWTs are structured, how to decode one safely, and a privacy trap to avoid.
What's inside a JWT
A JWT is three Base64URL-encoded parts joined by dots:
header.payload.signature
- Header — metadata, mainly the signing algorithm (e.g.
{"alg":"HS256","typ":"JWT"}). - Payload — the claims: who the user is (
sub), when the token expires (exp), who issued it (iss), and any custom data you added. - Signature — a cryptographic signature over the header and payload, used to verify the token wasn't tampered with.
The header and payload are not encrypted — they're just Base64URL-encoded, which means anyone can read them. That's by design, and it's exactly why decoding is so useful for debugging.
Decoding vs. verifying — an important difference
This trips people up constantly:
- Decoding a JWT means reading the header and payload. It requires no secret and proves nothing about authenticity — it just reveals the contents.
- Verifying a JWT means checking the signature against a secret or public key to confirm it's genuine and unmodified.
When you're debugging "why is this user getting a 401?", you almost always want to decode — to check the exp (is the token expired?), the sub (is it the right user?), or a custom claim (does it have the right role?).
How to decode a JWT step by step
- Open the JWT Decoder.
- Paste your token (the long
eyJ...string). - The header and payload are decoded and pretty-printed instantly, so you can read every claim.
Check the exp claim first — it's a Unix timestamp, and an expired token is the single most common auth bug.
Why you should be careful pasting tokens into online decoders
Here's the trap: a JWT is a live credential. Until it expires, anyone holding it can often act as that user. Many popular online JWT decoders send the token you paste to their server to decode it — which means you may be handing a working credential to a third party you don't control. For a production token, that's a genuine security risk.
The JWT Decoder here decodes entirely in your browser. The token is split and Base64URL-decoded by JavaScript on your machine — nothing is transmitted anywhere (check the Network tab and you'll see no requests). For something as sensitive as an auth token, client-side decoding isn't a nice-to-have; it's the responsible default.
Creating and signing test tokens
Debugging often means you also need to create tokens — a token with a specific claim, or an expired one to test your error handling. The JWT Encoder lets you build and sign test tokens (HS256/384/512) right in the browser, so you can reproduce edge cases without touching your auth server.
Try it
Paste your token into the JWT Decoder to read its claims — free, no signup, and nothing leaves your browser. Need to build test tokens? Use the JWT Encoder.