JWT Decoder

JWT decoding method and security boundary

This page decodes the readable header and payload segments of a JSON Web Token. It does not verify the signature, issuer, audience, expiration policy, key rotation, or revocation state. A token that displays valid JSON can still be forged, expired, intended for another service, or unsafe to trust.

Methodology

1. The compact token is split on periods into header, payload, and signature segments.
2. Base64url characters are converted for decoding and missing padding is handled as required.
3. The first two decoded byte sequences are interpreted as UTF-8 JSON and formatted for inspection.
4. The signature segment is shown only as token structure; no trust decision is made without the correct verification key and policy.

Worked review example

A payload may contain an exp number and an admin-looking claim. Decoding proves only that those bytes were present; it does not prove who created them. Production software must verify the allowed algorithm, signature, issuer, audience, time-based claims, and application-specific authorization using a maintained JWT library.

Test coverage and expected behavior

Test coverage includes a three-segment sample, Base64url characters, missing padding, malformed JSON, too few segments, and non-UTF-8 output. The interface confirms that the interface labels decoded claims as unverified. We do not use live account tokens in testing.

Decision checklist before using the output

Use decoding only to understand token structure during authorized development. Redact or replace every live token in screenshots, tickets, chat, and documentation because a bearer token can grant access until it expires or is revoked. After reading claims, verify them in the server implementation with a maintained library and a fixed algorithm allowlist. Check signature, issuer, audience, expiration, not-before time, key identifier handling, key source, and application authorization separately. Do not infer a user’s permissions from a decoded role claim without completing those checks. If a token appears in logs or has been shared with an unintended party, rotate or revoke it according to the provider’s process rather than assuming short expiry is enough. The page is suitable for fabricated samples and local debugging; it is intentionally incapable of declaring a token authentic.

Important limitations

• Never paste a live bearer token into a third-party site or support ticket.
• The alg header must not be accepted without an application allowlist.
• Clock skew and expiration policy require server-side rules.
• Decoding cannot detect revocation or prove that a user still has permission.

Sources and specifications

These references define the relevant format or browser behavior. They do not endorse WordCaseFix.

• RFC 7519 JSON Web Token
• RFC 8725 JWT Best Current Practices

Last reviewed: August 6, 2026