What Is a JWT? How to Decode a Token Without Sharing It

That distinction is the whole article. Search results mix “decode my JWT” with “verify my JWT.” They are different jobs. DevOkk’s JWT Decoder is for the first one, in the browser, without an account.

What the three segments actually are

Header. Almost always {"alg":"HS256","typ":"JWT"} or an RS256/ES256 variant. alg is which signature algorithm the issuer claims to have used. A decoder will show you that string. It will not check that the bytes match a key.

Payload. Claims. Registered ones you will keep seeing: iss (issuer), sub (subject), aud (audience), exp (expiration, Unix seconds), iat (issued at), nbf (not before). Application claims sit next to them: email, tenant, roles, feature flags. This is why people decode tokens. The network panel shows one line. You need errors in JSON, or exp as a date you can read.

Signature. Binary. You will see it as a third Base64url blob. Decoding the first two segments does not validate this blob. A token with a broken or empty signature can still pretty-print if the JSON is well-formed.

Encrypted JWTs (JWE) have five segments. A three-part decoder will reject them, correctly. If you expected JSON and got “invalid format,” check the segment count before you assume the tool is broken.

Decode is not verify

Verification means: recompute the signature with the correct key (HMAC secret or issuer public key) and compare. It also means checking exp, nbf, aud, and iss against the API you are calling. Libraries do that on the server. A paste-box that only runs atob on two segments does not.

DevOkk’s decoder will tell you the token has three parts and that those parts are JSON. Treat a green “decoded” state as “the string parsed.” Treat it as authentication and you will ship a vulnerable mental model into the next code review.

If you need to verify, do it in the service that already has the key. Do not paste the key into a website next to the token. That is worse than pasting the token alone.

Why people paste tokens into random sites

The token in the network panel is unreadable. jwt.io-style pages are the shortest path to pretty JSON. The cost is that the payload is often more sensitive than it looks: a work email, an internal user id, a list of scopes that maps your org chart.

You do not need a lecture about “never share secrets.” You need a default that still lets you debug at 4 p.m. when aud is wrong. A browser-local decoder is that default. The page loads over the network. The token is not uploaded to finish the decode.

If your company policy forbids any browser tool for production tokens, follow the policy. Use the staging token, or decode in a local script you already run. This article is not a compliance waiver.

How to decode in the browser

1. Copy the token only. If the header is Bearer eyJ..., you can paste the whole thing; the DevOkk tool strips a leading Bearer . Prefer copying just the three segments so you do not also grab a cookie.
2. Open JWT Decoder. There is no signup wall.
3. Paste. Read the header JSON and the payload JSON. Check exp first if the bug is “was valid an hour ago.” Convert Unix seconds in your head or a timestamp tool; 1710000000 is not a calendar date until you say it is.
4. Check aud and iss against the API and the auth server you think you are talking to. A valid-looking token for the wrong audience is a common 401.
5. Copy the claim you need into the ticket or the fixture. Do not screenshot the full token into Slack.
6. On a shared computer, clear the input. The tool may keep the last paste in local storage on that browser profile. Then close the tab.

If you only have a Base64 blob that is not a JWT, use Base64 Encoder instead. Forcing JWT structure onto a data URL wastes ten minutes.

What to look for once it is readable

Time claims. exp in the past explains a sudden logout. nbf in the future explains a token that “should work” on a machine with a bad clock.

Audience and issuer. Microservices are picky. A token minted for the admin UI will decode fine and still fail on the billing API.

Identity claims. sub is often an opaque id. Email and name are convenience, and they are also the reason not to paste the token into a public decoder.

Scopes and roles. If the payload says read:invoices and you are calling a write route, the decoder just saved you a wild-goose chase through CORS.

alg. none in a header is a historical attack class. If you see it, do not celebrate the pretty JSON. Ask why that token exists.

None of this replaces logging on the API. It tells you whether the client is sending the token you think it is.

What a decoder will not do

It will not refresh an expired token. It will not revoke one. It will not tell you if the signing key rotated last Tuesday. It will not decrypt a JWE.

It also will not make Base64 into encryption. The payload was never hidden. Anyone who intercepted the token can read the same claims you just did. HTTPS and storage discipline (memory, httpOnly cookies, short TTL) are what limit the blast radius. A decoder is a flashlight, not a lock.

Very large tokens (oversized claim sets, embedded profile photos as data) can be unpleasant in a textarea. If the browser chokes, you have a design problem in the token, not a missing cloud upload.

Decode the claims; do not treat it as encryption

If the job is “read the claims,” open JWT Decoder and stay there. If the job is “encode a different string,” use Base64 Encoder and remember it is still not encryption.

For the rest of the local toolkit - passwords, hashes, metadata - see Best Free Security and Encoding Tools. If you are still unsure whether the token should exist in a browser at all, decode a staging token and leave production in the network panel.