JWT Decoder

What this tool does

It splits a JSON Web Token on its dots, Base64url-decodes the first two segments, and prints them as formatted JSON with the timestamp claims converted to dates you can read. It is a debugging aid for the ten minutes you spend working out why an API keeps returning 401.

It runs in your browser and sends nothing anywhere. That is a necessary property, not a feature — a JWT is a live credential for as long as it is valid.

Interpreting the output: a worked example

An integration is failing intermittently. The token decodes to:

{ "alg": "HS256", "typ": "JWT" }
{
  "sub": "usr_8842",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "exp": 1770000000,
  "iat": 1769996400,
  "scope": "contacts:read"
}

Four things to check, in this order.

exp against the clock. Issued at iat, expiring one hour later. If the failures started roughly an hour after each deploy, the code fetched a token once at startup and never refreshed it. That is the single most common cause of intermittent 401s.

aud against the service you are calling. A token minted for https://api.example.com will be rejected by a different service even though it is perfectly valid. Copying a working token from one environment into another fails here.

scope against the operation. contacts:read will not let you write. A 403 rather than a 401 usually points at this.

alg in the header. HS256 is symmetric — the same secret signs and verifies. RS256 is asymmetric, and lets a receiver verify with a public key without holding anything secret. If a token you expected to be RS256 arrives as HS256, treat that as an incident rather than a curiosity; it is the shape of a well-known confusion attack.

Everything above comes from the payload, which brings us to the point that matters most.

Decoding is not verifying

The payload of a JWT is Base64url-encoded, not encrypted. Anyone holding the token can read every claim in it, and anyone can write their own token with "role": "admin" in it. The only thing separating a genuine token from a forged one is the signature, and checking that signature requires the key.

This tool does not verify signatures, because verifying would mean asking you for your signing key. Never paste a signing secret into a web page.

So: a claim shown here tells you what the token says. It tells you nothing about whether your server should believe it. The structure and the registered claims are defined in RFC 7519, and the practical rules for handling tokens safely are collected in RFC 8725, JSON Web Token Best Current Practices.

Standard claims

exp, nbf and iat are seconds since the Unix epoch, not milliseconds. A timestamp that decodes to a date in 1970 or in the year 57000 means someone has mixed up the units.

Common mistakes

Trusting a claim without verifying the signature. The whole security model rests on the signature. A library that decodes without verifying, called on a request path, is an authentication bypass.

Accepting whatever alg the token asks for. Pin the expected algorithm on the server. Accepting none, or accepting HS256 on a service that publishes an RSA public key, are both routes to forged tokens. The OWASP JWT cheat sheet sets out these cases and the mitigations in detail.

Putting sensitive data in the payload. It is readable by anyone who holds the token. Email addresses, internal ids and permission lists all leak.

Long expiry to avoid handling refresh. A twelve-hour token is a twelve-hour window for anyone who copies it out of a log. Short access tokens with a refresh flow is more work once and less exposure permanently.

Logging the whole Authorization header. Tokens end up in log aggregators, error trackers and support tickets. Redact them at the logger.

Assuming you can revoke one. A signed token is valid until it expires unless you maintain a deny list and check it on every request. Most systems do not.

FAQ

Is my token sent anywhere when I paste it here?

No. The decoding happens in your browser and nothing leaves the page. Even so, the safest habit is to use a development or staging token when debugging. Treat any production token that has been pasted into any web page as one you should rotate.

Why can I read the payload without a password?

Because a JWT is signed, not encrypted. Signing proves the contents have not been altered; it does nothing to hide them. If you need the contents hidden as well, that is JWE rather than JWS, and it is a different and heavier mechanism.

The token looks valid but the API returns 401. What now?

Work through exp, aud, iss and alg in that order, as in the worked example above, and check your server's clock. Small clock skew between the issuer and the verifier expires tokens early and produces failures that look random.

What is the difference between an access token and a refresh token?

The access token is the short-lived one you send with each request, and the one you are decoding here. The refresh token is longer-lived, held more carefully, and exchanged with the identity provider for a new access token. If your integration only ever fetches a token once, that is the missing piece.

How do I inspect the raw segments myself?

Split the string on dots and Base64url-decode each part. The Base64 Encoder and Decoder will do the middle step, and the API Tester is the faster way to confirm whether a token is actually accepted by the endpoint. Bearer token auth in the wider context of connecting business systems is covered in API automation for businesses.

Next step

Token handling is where most integrations quietly rot: no refresh, no clock tolerance, secrets in logs, and a 401 that surfaces as "the automation stopped working" three weeks later. If you want an integration built with the refresh flow and the failure handling done properly the first time, my API and automation work is on Fiverr.