Answer: Paste a JWT and decode its header and payload instantly — base64 and JSON shown side by side, all locally in your browser.
Decode JSON Web Tokens — inspect header, payload & signature
A JSON Web Token is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It has become the default format for authentication and authorization in web applications and APIs: after you sign in, the server issues a signed token that your client presents on subsequent requests, letting the server verify identity without a session lookup. A JWT is self-contained — the token itself carries the claims (user ID, roles, issuer, expiry) — which is what makes stateless APIs possible and also why being able to inspect one matters.
Decoding runs entirely in your browser. Paste a token and the tool splits, Base64url-decodes, and pretty-prints the header and payload locally; the token never leaves your device.
A JWT is three Base64url-encoded segments joined by dots:
typ: JWT) and the signing algorithm (alg), such as HS256 or RS256The signature is what lets a server trust the token: anyone can craft a payload, but only someone holding the key can produce a valid signature. This decoder shows all three parts and additionally interprets the exp and iat timestamps, marking expired tokens with a clear warning.
RFC 7519 defines a set of reserved claim names with defined semantics. The table below lists the ones you will encounter in almost every real-world token, including the two this tool checks for expiry and issuance.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token |
| sub | Subject | Who the token is about, usually the user ID |
| aud | Audience | Who the token is intended for; a server should reject tokens issued for a different audience |
| exp | Expiration time | Unix timestamp after which the token must be rejected |
| nbf | Not before | Unix timestamp before which the token is not yet valid |
| iat | Issued at | Unix timestamp when the token was created |
| jti | JWT ID | Unique identifier for the token, used to prevent replay |
The single most important distinction in JWT work: decoding is not verifying. The header and payload are only Base64url-encoded — an encoding, not encryption — so anyone can read them without any key. What you cannot do without the key is forge a valid signature. A server's job when receiving a token is to verify that signature and enforce the claims (expiry, audience, issuer); this tool's job is the developer-facing half: showing you what is actually inside a token so you can debug claim names, check timestamps, confirm an algorithm, or audit what a third-party service is sending. Never rely on decoded payload contents as proof of authenticity.
JWT payloads are readable by design, so tokens must never carry secrets, passwords, or sensitive personal data they don't need. Treat a bearer token as a credential: anyone holding it can act as the user until it expires. Short expiry windows and refresh tokens limit the blast radius of a leaked token. If you paste a production token into any online tool, you are trusting that tool — safe here only because decoding is purely client-side, but the habit is worth avoiding in general. Finally, be aware of the alg header's history: attacks such as alg: none and algorithm-confusion exploits worked by tricking verifiers into using the wrong algorithm, which is why verifiers must pin the expected algorithm rather than trust the header.
Real-world debugging sessions with JWTs follow a familiar arc: a request returns 401, and you need to know whether the token expired, was issued by the wrong party, or is missing a claim the API expects. Decoding answers all three in seconds — check exp against the current time, read iss against the expected issuer, and scan the payload for the claim name the server complained about. Common gotchas worth knowing: clocks matter (a token valid on the server may look expired on a machine with a skewed clock), refresh tokens are usually longer-lived JWTs or opaque strings separate from the access token, and a token that works in one environment but not another is often audience-mismatched, which the aud claim reveals immediately.
Is decoding a JWT the same as verifying it?
No. Decoding simply Base64url-decodes the header and payload so anyone can read them. Verification cryptographically checks the signature against the header's declared algorithm and the issuer's key. This tool decodes only and never verifies signatures.
Are JWT payloads encrypted?
No. The payload is Base64url-encoded, which is encoding, not encryption. Anyone who obtains the token can read its claims. If payload confidentiality matters, the token must be encrypted separately, for example as a JWE.
What standard claims appear in a JWT payload?
Common registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), and iat (issued-at), all defined in RFC 7519. Applications may add arbitrary public or private claims alongside them.
Why do JWT tokens expire?
The exp claim bounds how long a token is valid, limiting the damage if a token leaks. Once expired, conforming servers reject it and the client must obtain a new one, typically via a refresh token.
Is it safe to paste a production token into an online decoder?
It is safe here because decoding runs entirely in your browser and nothing is transmitted. As a general rule, avoid pasting live tokens into sites you do not control, and treat any bearer token as a password.