JWT Decoder

Start with the three dot-separated sections

A compact signed JWT is carried as three nonempty sections separated by dots. The first section contains the header, the second contains the payload, and the third carries the signature data. SnakTool requires exactly this three-part shape before it tries to decode the token.

The dots are structural separators, not decoration. A token with only two sections is incomplete for this decoder, while a five-part compact token belongs to a different JOSE structure such as JWE and is outside this page's supported input.

xxxxx.yyyyy.zzzzz
  │     │     │
header payload signature

Base64URL makes the header and payload readable without a key

The first two JWT sections use Base64URL, a URL-safe Base64 alphabet that uses - and _ where standard Base64 uses + and /. SnakTool decodes those sections as UTF-8 and then parses the resulting text as JSON.

This is decoding, not decryption. A signed JWT payload is not hidden merely because it appears as an encoded string, so secrets should not be placed in a readable payload on the assumption that only the application can inspect it.

The header describes how the token says it was handled

A JWT header can contain fields such as alg, typ or kid. For example, alg may name a signing algorithm and kid may identify a key. Decoding lets you inspect those values, which is useful when diagnosing why a token and a verifier disagree.

The header is still data supplied by the token. Reading alg: RS256 does not prove that an RS256 signature was successfully verified, and reading a key identifier does not establish that the key is trusted. Verification software must apply its own allowed algorithms and trusted-key policy.

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2026"
}

Payload claims are statements until verification gives them context

The payload can carry registered claims such as iss for issuer, sub for subject and aud for audience alongside application-specific claims such as a role. A decoder can show exactly what those fields say, but it cannot establish that the statements are authentic.

If a decoded payload says role: admin, that text alone must not grant administrator access. An attacker can construct or modify encoded JSON. The application accepting the token must verify the signature and apply the issuer, audience and authorization rules it requires.

{
  "iss": "https://auth.example",
  "sub": "user_123",
  "aud": "api.example",
  "role": "admin"
}

Numeric time claims are seconds, not JavaScript milliseconds

JWT NumericDate values are expressed as seconds from the Unix epoch. SnakTool looks for numeric exp, nbf and iat claims, multiplies those values by 1000 for JavaScript Date conversion, and shows an ISO date when the resulting date can be represented.

The three claims answer different questions: iat records when the token says it was issued, nbf specifies a time before which it should not be accepted, and exp specifies its expiration time. A common integration mistake is supplying a JavaScript millisecond timestamp where JWT expects seconds.

An expired token can still be perfectly decodable

Decoding answers whether the token's header and payload can be interpreted; acceptance is a separate decision. A token whose exp value represents a time in the past can still have valid Base64URL, valid UTF-8 and valid JSON, so there is nothing about expiration that prevents its contents from being displayed.

SnakTool converts supported time claims for inspection but does not turn those dates into a security verdict. A verifier needs its own current-time checks, clock-skew policy and claim requirements before deciding whether a token is acceptable.

The signature is present, but this decoder does not verify it

The third JWT section matters because signed-token verification binds the protected header and payload to signature data under the required algorithm and key. SnakTool requires a nonempty third section as part of the three-section token shape, but it does not ask for a secret, public key or JWKS and does not verify that signature.

This creates the most important boundary on the page: successful decoding means you inspected structured data, not that you authenticated it. Use a JWT verification library with trusted key material and an explicit validation policy wherever a security decision depends on the token.

Parsing success establishes structure, not trust

SnakTool is intentionally strict about the parts it does parse. The header and payload must contain valid Base64URL data, decode to valid UTF-8, parse as JSON, and produce JSON objects rather than arrays or primitive values.

Those checks can explain malformed-token errors, but none of them proves who created the token. A fabricated token can be well formed. Structural validity and cryptographic authenticity answer different questions.

Five compact sections point to a different job

A three-part signed JWT and a five-part compact JWE are not interchangeable formats. JWE is designed for encrypted content and uses five compact sections, so its contents cannot be handled by simply treating it as the three-part input expected here.

SnakTool's JWT Decoder rejects a five-section token because it requires exactly header, payload and signature sections. If the token is a JWE, it needs the corresponding decryption process and key material rather than this decoder.

Signed JWT / JWS:  part.part.part
Compact JWE:       part.part.part.part.part

Treat a live token as a credential even when you only want to inspect it

JWTs copied from production systems can carry identity, authorization and session-related information. The fact that the payload is readable does not make the complete token harmless to expose.

Prefer synthetic or deliberately non-sensitive tokens for debugging examples. When a real credential must be investigated, handle it according to the security rules of the system that issued it and avoid sharing it more widely than necessary.

References

• RFC 8725: JWT security practices