JWT Decoder
Decode a JSON Web Token header and payload (no signature verification).
- Free · no sign-up
- Instant results
- Privacy-friendly
Other Developer Tools
What a JWT actually is
A JSON Web Token is three Base64url-encoded segments joined by dots: header, payload, and signature. The header says which algorithm signed the token. The payload carries the claims — who the token is about, who issued it, when it expires. The signature proves the first two segments have not been altered since the issuer created them.
Paste a token here and the first two segments are decoded and pretty-printed so you can read them. This is the fastest way to answer the questions that come up constantly while debugging auth: is this token expired, which user is it actually for, which issuer minted it, and does it carry the scope the API says is missing.
The thing people get wrong: a JWT is signed, not encrypted
The payload is encoded, not protected. Base64url is a transport encoding that anyone can reverse in one line of code — which is exactly what this page is doing. Anyone who obtains the token can read every claim inside it.
The practical consequence is that a JWT payload is the wrong place for anything confidential. Do not put passwords, full card numbers, government identifiers, medical details, or internal secrets in claims. Put an opaque user ID in the token and look the sensitive data up server-side. What the signature guarantees is integrity and authenticity — that the claims have not been tampered with — never secrecy.
Decoding is not verifying
This tool deliberately does not check the signature, because doing so would require you to hand over your signing key or public key, and no debugging convenience is worth that.
So treat what you see here as "what the token claims about itself", not "what is true". A token whose payload says admin: true tells you nothing about whether your server would accept it. Signature verification belongs in your application, using your own key and a maintained JWT library — and that library must pin the expected algorithm rather than trusting the alg field in the header, since accepting the header's claim at face value is the classic alg:none and RS256-to-HS256 confusion vulnerability.
Reading the standard claims
Most tokens use the registered claim names from RFC 7519. These are the ones worth recognising on sight:
- exp — expiry. A Unix timestamp in seconds. If it is in the past, the token is expired and a correct server will reject it. This is the first thing to check when a token stops working.
- iat — issued at. When the token was created. Useful for spotting clock skew between your services.
- nbf — not before. The token is invalid until this time; a common cause of "it works on my machine" when server clocks disagree.
- iss — issuer. Which service minted the token. Your API should check this matches the issuer you expect.
- aud — audience. Who the token is intended for. A token minted for a different audience should be rejected even if the signature is valid.
- sub — subject. The user or entity the token is about, usually an opaque internal ID.
- jti — a unique token ID, used to support revocation lists.
Privacy
Decoding happens to build the response and the token is not written to disk or kept afterwards. Even so: a bearer token is a live credential for as long as it is valid. If you paste a production token anywhere — here or in any other online decoder — treat it as exposed and rotate it. For routine debugging, prefer a test-environment token.