Decodes the header and payload of a JWT without verifying the signature.
—Decodes the header and payload of a JWT without verifying the signature.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwibmFtZSI6IkFkYSJ9.sig
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1","name":"Ada"}Only the two Base64 sections are decoded.
The output shows what the token claims; verification requires the issuer's key.
Your input is processed entirely in your browser and never sent to a YAS server.
curl -X POST "https://yas.sh/api/v1/tools/jwt-decoder" \
-H "Content-Type: application/json" \
-d '{"input":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.sig"}'const res = await fetch("https://yas.sh/api/v1/tools/jwt-decoder", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"input": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.sig"
}),
});
const data = await res.json();import requests
r = requests.post("https://yas.sh/api/v1/tools/jwt-decoder", json={"input":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.sig"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| input | string | Yes | The 3-segment token |
{ "slug": "jwt-decoder", "result": { "header": {...}, "payload": {...} }, "warning": "Decoded WITHOUT signature verification" }Decode a JWT header & payload (NO signature verification — explicitly flagged).
400 VALIDATION_ERROR — invalid input or unsupported option.413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).A JSON Web Token in compact serialization is three Base64URL segments joined by dots: header.payload.signature. Decoding splits on the dots and Base64URL-decodes the first two segments into JSON. The header names the algorithm (alg) and optionally the key (kid); the payload carries the claims. Both are plain text to anyone holding the token — a JWT is signed, not encrypted.
The signature covers the ASCII bytes of header.payload exactly as they appear, which is why you cannot edit a claim and re-join the segments — every change invalidates the signature under the signing key. Verification requires that key, so a browser-side decoder deliberately stops at decoding and does not claim to verify.
Registered claims from RFC 7519 have defined meanings: exp (expiry), nbf (not before) and iat (issued at) are NumericDate values — seconds since the Unix epoch, not milliseconds. iss, aud and sub identify issuer, audience and subject. A validating server must check exp, nbf, iss and aud; skipping the audience check is a common vulnerability that lets a token minted for one service be replayed against another.
Decode the token and read exp against the current epoch seconds. An expired token, a clock skew of a few minutes, or an aud that does not match the API you are calling explains the majority of unexpected 401 responses.
Provider documentation and provider behaviour drift. Decoding a real token shows the exact claim names, whether roles arrive as an array or a space-delimited string, and whether the email claim is present at all.
Decoding reveals over-sharing: personal data, internal IDs and permission lists that are readable by anyone who obtains the token. Anything sensitive in a payload should move server-side behind an opaque reference token.
Read alg and kid from the header. A kid that no longer appears in the issuer's JWKS means the key was rotated; alg: none or an unexpected HS256 where RS256 was expected is an active attack signature and must be rejected.
What this tool deliberately does not do, and where it will disagree with other implementations.