JWT Decoder

A JSON Web Token is three Base64URL-encoded segments joined by dots: a header describing the signing algorithm and token type, a payload holding the actual claims — who the token identifies, when it expires, what permissions it grants — and a signature computed over the first two segments using a secret or private key. Decoding, which is what this tool does, means Base64URL-decoding the first two segments back into readable JSON; it says nothing about the third segment beyond exposing its raw encoded value, because verifying that signature requires the actual signing secret, which a browser-based tool should never be asking you to paste in.

This distinction — decode versus verify — is the single most important thing to understand about a JWT debugging tool. Decoding tells you what a token *claims*; verifying tells you whether those claims can be *trusted*, by confirming the signature was produced by the expected issuer. A token can decode perfectly and display a payload claiming administrator access while being entirely forged, if nothing ever checks the signature against the real signing key.

The header and payload are encoded, not encrypted — Base64URL is a reversible transformation with no secret involved, so anyone who obtains a token, whether by intercepting network traffic, reading browser storage, or being handed it directly, can decode the payload and read every claim inside it without needing any key at all. This is precisely why the standard advice is to keep JWT payloads limited to identifiers and non-sensitive claims — a user ID, a role, an expiry time — and never to place a password, a credit card number, or any other Confidential data directly inside the token, because the token format provides no confidentiality whatsoever on its own.

The standard timestamp claims are stored as Unix time — a plain integer counting seconds since January 1, 1970 — which is efficient for machines to compare but unreadable at a glance for a person debugging a token by eye. Converting `1735689600` into "January 1, 2025, 00:00:00 UTC" by hand is exactly the kind of small, error-prone arithmetic that is easy to get wrong under time pressure, particularly across time zones. Rendering all three claims as actual local dates, and stating outright whether the token is currently expired, valid, or not yet active, turns a debugging session that would otherwise involve a side calculation into an immediate, readable answer.