How to Decode a JWT Token

Decoding a token is a daily reality for anyone who works with authenticated APIs. The most common reason is debugging: a request is being rejected and you want to confirm the token has the right user, the right scopes, and an expiry that is still in the future. The exp claim is in Unix time, so decoding lets you actually read it instead of guessing.

It is also useful for learning and integration work. If you are wiring up a new identity provider or single sign-on flow, decoding the tokens it issues tells you exactly which claims are present and how they are named — far faster than reading the spec and hoping the provider followed it. And during a code review or incident, pasting a captured token quickly answers "whose token is this and what could it do?"

Yes. The JWT Decoder does all of its work in your browser using your device's own JavaScript. Your token is never sent to Tooldrop or any server — there is no upload step at all. When you close or refresh the tab, the token is gone with it.

That matters because JWTs are often sensitive. A valid token can frequently be replayed to impersonate a user until it expires, so pasting one into a random online decoder that ships it off to a backend is a real risk. Because this tool keeps everything local, you can safely inspect production and staging tokens. As a habit, still avoid pasting tokens into shared screens or chat logs, and treat any live token like a password.

The decoder splits your token on its dots and base64url-decodes the header and payload, then formats them as clean, indented JSON so they are easy to scan. The signature segment is shown exactly as it appears in the token.

What it deliberately does not do is verify the signature. Verification proves a token was issued by a trusted party and hasn't been tampered with, and that requires the issuer's secret or public key — something a viewer should never ask you to hand over. So "decoded" here means "made readable," not "proven authentic." Reading a payload tells you what a token claims; it does not prove the token is genuine. Never trust the contents of a decoded token for a security decision in your own code without verifying the signature there.

Paste the whole token and nothing else. The most frequent error is leaving the word "Bearer" (and its space) at the front when copying from an Authorization header — strip that off so the string starts with the header segment. Stray quotes, trailing commas, or line breaks copied from JSON can cause the same problem.

If you see a message about needing three parts separated by dots, you have probably grabbed only part of the token or an extra fragment. If you see a base64url, UTF-8, or JSON error, the token is truncated or corrupted in transit — re-copy it from the source. And remember the payload is just data: a far-future or already-passed exp is normal to see, and the decoder will happily show you an expired token because reading and validating are two different jobs.