JWT Decoder

A JWT decoder turns the visible parts of a token back into readable JSON so you can inspect authentication data without manually splitting Base64URL segments. It is most useful when a login, API call, environment switch, or permission check fails and you need to see what the token claims, not when you need to prove the token is trustworthy.

Tool boundary

This page is scoped to decoding and inspection. It does not ask for a secret or public key, does not verify the signature, and does not generate or re-sign JWTs.

A JWT is three Base64URL segments, not an encrypted blob

A common signed JWT is written as `header.payload.signature`. The header and payload are normally JSON encoded with Base64URL, which uses URL-safe characters and may omit padding. Anyone holding the token can decode those two JSON objects, so payload readability is expected and should not be confused with authorization.

• Header: describes metadata such as token type and the intended signing algorithm.
• Payload: carries claims about the subject, issuer, audience, time limits, scopes, or business-specific facts.
• Signature: protects the encoded header and payload, but it is meaningful only after verification with the correct key material.

Registered claims you should recognize

How to use this tool

1. Paste the complete three-part JWT so the workspace can decode both the header and the payload claims.
2. Inspect the algorithm, issuer, audience, and exp or nbf timestamps before deciding what you need to verify next.
3. Use the decoded view for inspection only, then verify the signature and required claims in the real authentication system.

A practical reading order for decoded JWTs

Read a decoded JWT in a stable order so you separate formatting issues from real authentication failures. First confirm that the token has the expected segment count, then inspect the algorithm and type, then read the claims that control issuer, audience, time, subject, and scope.

1. Check `typ` and `alg` in the header before reasoning about the payload.
2. Translate time claims into the timezone used by the system logs you are comparing against.
3. Treat decoded custom claims as evidence to inspect, not as permission to grant access.

JWT Decoder example

This JWT Decoder example uses representative JWT strings containing Base64URL header, payload, and signature parts and shows the resulting readable JSON for the token header and payload, so you can confirm three-part token shape, Base64URL decoding, exp and nbf times, issuer, audience, and the fact that decoding is not signature verification before applying the same settings to real input.

Sample input

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature

Expected output

{
  "alg": "HS256"
}
{
  "sub": "123"
}

Decoded header and payload example

Header:
{ "alg": "HS256", "typ": "JWT" }

Payload:
{
  "sub": "toolkit-user",
  "name": "ToolKit Online",
  "iat": 1700000000
}

Signature:
present, but not verified by this decoder

Safe decoding-only pseudocode

parts = token.split(".")
if parts.length < 2:
  rejectAsMalformed()

header = parseJson(base64UrlDecode(parts[0]))
payload = parseJson(base64UrlDecode(parts[1]))
signatureSegment = parts[2] || ""

show(header, payload, signatureSegment)
warn("decoded output is not signature verification")

Where a JWT decoder is most useful

A decoder is a visibility tool for authentication and authorization debugging. It gives developers, support engineers, and API owners a common way to discuss what the token says before they inspect server-side signature verification, key configuration, or authorization rules.

• Confirm whether a frontend is sending a staging token to production or the reverse.
• Compare `aud`, `iss`, and scope claims when one API accepts a token and another rejects it.
• Check whether `exp`, `nbf`, or clock skew explains a sudden login or refresh failure.

Common Use Cases

JWT Decoder is most useful when JWT strings containing Base64URL header, payload, and signature parts must produce readable JSON for the token header and payload for login debugging, API authorization checks, environment mismatches, permission claims, and support investigations.

• Use it to decode JWT header and payload claims locally for login debugging, API authorization checks, environment mismatches, permission claims, and support investigations.
• Use the sample workflow to confirm three-part token shape, Base64URL decoding, exp and nbf times, issuer, audience, and the fact that decoding is not signature verification before processing important input.
• Copy or download readable JSON for the token header and payload once it matches the destination workflow.

What the Decoder Helps You Check

The decoder is most useful during authentication debugging, environment verification, and claim inspection. It narrows the problem quickly, but final trust decisions still belong to the live auth stack.

• Use the decoded payload to inspect claim presence, not to bypass server-side verification rules.
• Review `exp`, `nbf`, `iss`, `aud`, and algorithm metadata together when investigating auth failures.
• Remember that Base64URL formatting details can differ slightly from standard Base64 assumptions.

Decoding is not verification

This is the single most important boundary. A decoder can reveal claims, but it cannot tell you whether the token was issued by a trusted signer, whether the signature is valid, or whether the token should still be accepted by the real authentication system.

• Always review `exp`, `nbf`, `iss`, `aud`, and any domain-specific claims in their real validation context.
• Treat copied production tokens carefully because payload data may contain account or session details.

Algorithms are header context, not a local trust result

Values such as `HS256`, `RS256`, or `ES256` tell you what algorithm the token says was used. A real verifier must still enforce an allowed algorithm list, select the correct secret or public key, reject unexpected `alg` values such as unsecured tokens, and validate required claims after signature verification.

• Do not accept an algorithm just because it appears in the token header.
• Do not put passwords, secrets, private keys, or sensitive customer data in the payload because decoded payloads are readable.
• Use short lifetimes, HTTPS transport, key rotation, and server-side revocation or refresh-token design where the real product requires them.

JWT inspection actions compared

JWT compared with nearby token styles

Practical Notes

• Review three-part token shape, Base64URL decoding, exp and nbf times, issuer, audience, and the fact that decoding is not signature verification before you reuse the readable JSON for the token header and payload.
• Do not trust a decoded JWT unless the real authentication system also verifies the signature and required claims.
• Keep the original JWT strings containing Base64URL header, payload, and signature parts available when the result affects production work or customer-visible content.

JWT Decoder reference

JWT Decoder should explain JWT header, payload, signature, expiration, and the difference between decoding and verification.

• JWTs normally contain three Base64URL parts: header, payload, and signature.
• Header and payload are just JSON encoded with the URL-safe Base64 alphabet, while the signature is computed over the ASCII form of `header.payload`.
• The signature algorithm may be symmetric like HS256 or asymmetric like RS256/ES256, but decoding alone never proves trust.
• Check exp, nbf, iss, aud, and signature verification in the real authentication system.

References

• RFC 7519: JSON Web Token (JWT)
• RFC 7515: JSON Web Signature (JWS)
• RFC 8725: JSON Web Token Best Current Practices