Skip to content
OmniTools

JWT Decoder

Decode a JSON Web Token to inspect its header and payload, entirely in your browser.

All developer tools

JWT decoder

Claims

Payload

exp and aud are the two most frequent causes of a rejected token. Note that exp is a Unix timestamp in seconds, not milliseconds.

Header

This decodes the token, it does not verify it. The signature cannot be checked without the issuer's key, so a token that decodes cleanly may still be forged, expired, or signed by the wrong party. Never treat a decoded token as authentic. The payload is also readable by anyone holding the token, so it must never contain a secret.

This tool runs entirely in your browser. Nothing you enter is uploaded, stored, or logged.

What this tool does

A JSON Web Token is three Base64url-encoded segments separated by dots. Decoding one shows the header and the payload, which is useful when debugging a rejected request or understanding what a token claims. Decoding is not verification, and the distinction is the most important thing to know about this tool.

How it works

A JWT has three parts: a header naming the algorithm, a payload carrying the claims, and a signature. The first two are encoded but not encrypted, so anyone holding the token can read them. That is why a JWT payload must never contain a secret, a password, or card details, and why putting personal data in a JWT is a data protection problem rather than a security measure.

Verification is a separate step. The signature is checked using the issuer's key to confirm the token was not altered and was actually issued by the party you trust. This tool does not have that key and does not check it, so a token that decodes cleanly here may still be forged, expired, or signed by the wrong party.

The payload's exp and nbf claims are Unix timestamps and the tool shows them as dates, because an expired token is one of the most common reasons a request is rejected. It reports the expiry status but does not treat decoding as proof the token is valid.

Worked example

Debugging a 401 response and inspecting the claims on the token that was sent.

  1. Split the token on the dots to get three segments
  2. Base64url-decode the header and payload
  3. Read exp, iat, iss, and aud

The payload shows an exp that passed an hour ago, which explains the rejection. The token decoded fine; it is simply expired.

Accuracy and limitations

  • This tool decodes but never verifies. Do not use it to decide whether to trust a token.
  • The algorithm field is read from the token and is not a security control. Never trust the alg value to decide how to verify.
  • Base64url uses a different alphabet from standard Base64, so a decoder that does not handle it will produce garbage.

Frequently asked questions

Is a JWT encrypted?
No, not unless it is a JWE, which is a different and rarer format. A JWS, which is what almost everyone means by JWT, is signed but its payload is readable by anyone. Treat the payload as public information.
Is it safe to paste a JWT here?
This tool decodes locally and transmits nothing, so the token does not leave your browser. Even so, a JWT is a live credential while it is valid, so treat pasting one anywhere as something to do sparingly.
Why does my token fail even though it decodes?
Decoding only proves the token is well-formed. Rejection is usually an expired exp claim, a wrong audience or issuer, a bad signature, or a clock skew on your server. Check the dates and the aud and iss claims first.
What are the common claims?
sub for the subject, usually a user ID. iss for the issuer. aud for the intended audience. iat and nbf for issued-at and not-before times. exp for expiry. jti for a unique token ID, used to support revocation. exp and aud are the two most frequent causes of rejection.