JSON Web Token (JWT) decoder tool | ZeroTools

JSON Web Token (JWT) is an open, compact, claim-based data representation standard defined in RFC 7519, widely used in distributed identity, single sign-on, and API authorization mechanisms.

Although the broader specifications accommodate both signed tokens (JWS) and encrypted tokens (JWE), this debugging utility is tailored specifically for standard three-part compact JWS strings, composed of a Header, a Payload, and a Signature separated by dot (.) delimiters, without supporting JWE structures.

Reusing the robust core decoding pipeline from the Japanese engine, the tool splits the supplied input into three required segments.

Each of the first two segments (Header and Payload) must be composed solely of non-empty ASCII characters within the set [A-Za-z0-9_-]+ and must have a length modulo 4 not equal to 1.

The application restores URL-safe Base64URL characters (- and _) back to standard Base64 (+ and /), appends necessary padding characters (=) internally, and decodes the string with atob into raw binary byte units.

These bytes are processed through a fatal UTF-8 TextDecoder that strictly rejects invalid UTF-8 sequences instead of falling back to Latin-1 encoding, after which the decoded text is parsed via JSON.parse.

The tool does not enforce JSON object types for root payloads, nor does it validate canonical padding bits, signature segment character formatting, or cryptographic signatures.

Decode outputs are calculated completely synchronously from the active input token via useMemo, ensuring that no stale decode data lingers after edits.

Finally, the third segment (the Signature) is simply presented in its raw string representation without cryptographic verification, and provided dummy sample tokens are purely illustrative and not cryptographically verifiable.

This utility makes no claim of strict JWT security validation.

Inside the decoded payload, the data that forms the substance of the token is stored as key-value pairs called "claims". In RFC 7519, standard key names called "Registered Claims" are defined to enhance interoperability.

Representative examples include iss (Issuer) indicating the issuer, sub (Subject) indicating the target user, and aud (Audience) indicating the expected recipient.

These claims are used to share the authentication context between systems. However, this tool does not enforce a strict JSON object type for the payload.

The payload display feature hierarchically formats these JSON structures, applying visual indentation so developers can quickly grasp the keys and values, though it does not provide syntax highlighting.

While a JWE (not supported by this tool) encrypts its contents, a JWS payload is merely encoded in Base64URL and the data itself is not encrypted.

This means any third party who obtains a JWS token can view the entire contents of the payload simply by using a decoding tool. Therefore, including confidential information such as passwords, personal identification numbers, or credit card numbers in a JWS payload is a severe security design flaw.

Developers must design their data on the premise that the contents of a JWS are readable.

Among the registered claims defined in RFC 7519, the time-centric claims exp (Expiration Time), nbf (Not Before), and iat (Issued At) play fundamental roles in governing token lifecycles and validity windows.

Standard specifications represent these timestamps as NumericDate values—JSON numeric types denoting total seconds elapsed since the Unix epoch (1970-01-01T00:00:00Z UTC)—where non-integer floating-point values are explicitly allowed and retained.

In this utility, an auxiliary expiration preview evaluates the exp claim strictly when it satisfies both typeof number and Number.isFinite(exp).

Any non-finite values (such as NaN or Infinity), strings, or boolean representations are entirely ignored and never trigger or function as active expiration timers.

When a valid finite numerical exp is present, it is multiplied by 1000 to convert seconds to milliseconds; if that resulting timestamp falls outside the valid representable range of JavaScript Date objects, the interface renders a graceful cannot-format notification rather than emitting an unhandled exception or an Invalid Date error string.

The remaining time calculation relies exclusively on the local client browser's system clock without contacting any remote time servers, meaning network clock skew, leap-second adjustments, and server-side synchronization margins are never evaluated.

Furthermore, the tool performs no validation whatsoever on other security-critical claims, such as nbf, iat, aud (Audience), iss (Issuer), or alg (Algorithm header).

Evaluated expiration status must never be conflated with token authenticity, cryptographic trustworthiness, or real-world validity.

Showing a token as active or unexpired merely offers a convenient, passive reference for local inspection and conveys zero security guarantees.

The third segment of a JWT, the Signature, is data attached to prevent token tampering. Based on the RFC 7515 (JSON Web Signature: JWS) specification, it stores a value calculated from the header and payload using a specific algorithm.

For example, if the header's alg claim is RS256, a signature using an RSA private key is calculated, which can be verified using the corresponding public key.

Alternatively, if the claim is HS256, it uses an HMAC algorithm where the same symmetric shared secret is used for both signing and verification, whereas asymmetric algorithms like RS256 rely on a private key for signing and a public key for verification.

This tool simply extracts the third dot-separated segment as the "signature portion" and displays it on the screen. This allows you to visually confirm that the token has a structure accompanied by signature data, distinguishing the signature from the decoded payload.

However, this tool only provides this raw signature string display, and performs absolutely no signature verification to check if that signature is correct.

In fact, the sample signature loaded by the tool is a fixed dummy string and not a verifiable valid signature. Because it does not verify signatures, it does not guarantee the authenticity of the header or payload, nor does it detect attacks exploiting vulnerabilities in the alg claim specification.

Token tampering detection and reliability confirmation must always be implemented on the backend server side using an appropriate JWT library and strictly managed keys.

During the process of development and debugging, the task of checking the contents of issued JWTs occurs frequently. This tool is a utility for smoothly performing such daily data confirmation.

The decoding processing of this tool is designed to be performed within the browser, using JavaScript to execute Base64URL conversion and JSON parsing on local memory.

By executing the processing on the client side without going through an API, it achieves a fast response where parsing results are immediately reflected on the screen.

However, even though the tool's processing is completed within the browser, carelessly handling actual production tokens is not recommended.

An access token issued in a production environment is vital authentication information that grants access rights to APIs. The copy function awaits the Clipboard API before displaying a success message for about two seconds.

If copying fails, an error is shown so you can manually select and copy the selected token, header, or payload text. Token leakage risks remain due to external factors, such as inadvertently showing a production token on screen during a screen-sharing meeting, a copied token being stored long-term in a clipboard management tool, or it remaining in the history of a shared PC's browser.

Therefore, as a general rule, ensure that you only use tokens issued in a local development or testing environment when checking decodes.

We outline the procedures for safely and effectively utilizing this tool during API development or OAuth 2.0 / OpenID Connect integration testing.

First, when investigating the cause of an authentication error that occurred in communication between the frontend and backend, decode the test environment's token with this tool to check if it has the expected payload structure.

By visually checking whether arrays or nested objects are correctly serialized as JSON and whether there are typos in key names, implementation errors can be found early.

Second, when you modify the token generation logic, load the generated test token into this tool to check if alg and typ in the header are set as expected.

Third, regarding the jti claim, remember that it is merely an identifier; its presence alone does not guarantee the prevention of replay attacks.

If you absolutely must understand the actual token structure for an incident investigation in a production environment, consider generating a dummy token that mimics only the structure and inputting it into the tool, or running a CLI script that performs the same processing as this tool's decode function on a secure local terminal.

This tool is purely a "viewer" specialized in quickly visualizing Base64URL and JSON structures, not a security tool that guarantees authenticity or performs vulnerability diagnosis.