Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Decode a JSON Web Token's header and payload for inspection.
Paste a JWT to decode its header and payload. This does not verify the signature.
A JSON Web Token (JWT) is a compact, URL-safe token format widely used for authentication and authorization -- it consists of three Base64URL-encoded, dot-separated parts: a header, a payload (the actual claims), and a signature. This tool decodes the header and payload back into readable JSON for inspection and debugging.
Paste a JWT (the full header.payload.signature string). The decoded header and payload appear as formatted JSON.
Decoding a JWT's header and payload requires no secret -- they're just Base64URL-encoded JSON, readable by anyone. Verifying the signature (proving the token wasn't tampered with) requires the issuer's signing secret or public key, which a client-side browser tool never has access to. Never trust a decoded JWT's claims as authentic without server-side signature verification.
The token is split on its 2 dots into 3 segments. The first two (header, payload) are Base64URL-decoded and parsed as JSON. The third (signature) is left as-is, since it's not human-readable data -- it's a cryptographic value.
exp) claim during developmentFor encoding/decoding the raw Base64URL segments manually, see the Base32 Encoder/Decoder-adjacent Base64 Encoder/Decoder.
Imagine a hypothetical token whose decoded header shows an algorithm field and a type field, and whose payload contains a subject, an issued-at value and an expiration value. Start with the header: the alg field tells you which signing method the issuer used, and typ normally says JWT. Move to the payload, where the claims live. Common registered names include sub for the subject, iss for the issuer, aud for the intended audience, exp for the expiry, nbf for "not before", and iat for the time it was issued. Custom claims, such as a role or a tenant identifier, sit alongside them and are specific to the application that issued the token.
The exp, nbf and iat values are Unix timestamps measured in seconds, not milliseconds. A ten-digit number is a seconds value; a thirteen-digit number would be milliseconds and suggests a non-standard issuer. This tool shows the raw number rather than converting it to a calendar date, so paste it into a timestamp converter to see the human-readable moment. A frequent debugging scenario is a login that suddenly fails: decode the token, compare the exp value with the current time, and you will often see the token has simply expired. Clock differences of a minute or so between servers can also cause a not-yet-valid or just-expired result, which is why many systems allow a small tolerance.
The input must contain exactly three dot-separated parts. If you paste a token with a prefix such as the word Bearer, extra spaces inside, or surrounding quotes, the decoder will fail, so copy only the token string itself (leading and trailing whitespace is trimmed). Both the header and payload must decode from Base64URL into valid JSON; if either does not, you will see a message saying the segments are not valid Base64URL JSON. Encrypted tokens (the JWE format) have five parts rather than three and cannot be read this way, since their content is genuinely hidden rather than merely encoded. The signature segment is shown untouched, and it is not checked in any way.
A live token can be used to act as its owner until it expires, so treat it like a password. Where possible, decode tokens from a development or staging environment, or generate a short-lived test token. If you did paste a production token somewhere you should not have, revoke or rotate the session according to your own system's procedures, and consult your security team for policy. For understanding the algorithm choices themselves, such as the difference between shared-secret and public-key signing, the relevant standard and your identity provider documentation are the authoritative sources.
Pay attention to an alg value of "none". A token that declares no signature algorithm should never be accepted by a properly configured server, and a decoded header showing it during testing is a good prompt to check that your verification library explicitly rejects such tokens.
No -- signature verification requires the issuer's secret or public key, which this client-side tool doesn't have. It only decodes the readable parts for inspection.
The decoding happens entirely in your browser (nothing is sent to a server), but as a general practice, avoid pasting live authentication tokens into any third-party tool -- use a local/expired test token when possible.
"exp" is a standard JWT claim for the token's expiration time, as a Unix timestamp -- many systems use it to automatically reject expired tokens.
A signed JWT is header.payload.signature, so exactly two dots are expected. Remove any prefix like Bearer or stray quotes, and check the token was not cut off when copied.
By the JWT convention they are in seconds since the Unix epoch. The tool displays the raw number, so convert it with a timestamp tool to see the date and time.
No. Encrypted tokens have five parts and hide their contents. This tool only handles standard signed tokens whose header and payload are Base64URL-encoded JSON.
No. Decoding only reads the claims. Validity depends on the signature, expiry, issuer and audience checks performed by your server.
Reference: MDN Web Docs