What a JWT decoder reveals
A compact signed JSON Web Token normally has three dot-separated parts. The first encodes a header, the second encodes claims in the payload, and the third carries a signature. This page decodes the first two Base64url parts as UTF-8 JSON so that you can inspect what a token says. Decoding is reversible representation work: it does not prove that the issuer created the token, that nobody altered it, or that the signature is valid. The original token remains in your browser during this operation.
The header may name an algorithm and token type. The payload can contain a subject, issuer, audience and custom application claims. The tool displays those objects separately because their roles differ. Treat every displayed value as untrusted input until the application has applied its own token-validation policy. A header that merely names a strong algorithm is not evidence that a valid signature was checked.
Read the time claims without mixing units
JWT time claims such as exp, nbf and iat use NumericDate values measured in seconds since the Unix epoch. If exp is 2,000,000,000, it means two billion seconds, not milliseconds. The decoder converts supported numeric time claims into readable UTC dates beside their raw values. This helps when a service rejects a token that is expired, not yet valid or unexpectedly issued. The displayed date is an interpretation of a claim, not a validation result.
For example, paste the sample token and compare the payload’s exp number with the UTC date shown below it. If a producer accidentally writes a 13-digit millisecond timestamp into exp, the date will be implausibly far in the future or outside a useful range. Fix the producer rather than dividing or multiplying the displayed claim without understanding its format. Local time zones can change how a clock displays the same instant, so use UTC when comparing logs.
A practical debugging workflow
Copy a test token from a controlled development environment, decode it, and inspect whether the expected issuer, audience and subject are present. Compare exp and nbf with the time at which the request failed. If the payload looks right but the server still rejects it, investigate signature verification, key selection and application policy on the server. The decoder cannot tell you whether the token was accepted by that server.
Because a payload is only encoded, it may contain names or other private information that anyone holding the token can read. Avoid placing real access tokens in bug reports, screenshots, URLs or public examples. This browser-local tool does not upload the pasted token for conversion, but copying the output or sharing the browser screen is still a separate disclosure decision.
Limits and common mistakes
A five-part encrypted JWE is not a three-part signed JWT and is outside this decoder’s scope. Likewise, a malformed Base64url segment, invalid UTF-8 or a non-object JSON header is rejected instead of being silently repaired. The tool reads claims but does not fetch keys, verify a JWS signature, check allowed algorithms, compare an expected audience or enforce clock skew. Those checks belong in a properly configured validation library.
Do not infer authorization from a decoded role or permissions field. A modified token can display a convincing admin claim while having an invalid signature. Also avoid treating a future exp date as sufficient: an application may reject the token for issuer, audience, revocation or other reasons. Use this page to understand the structure and make debugging more precise, then rely on the verifier for trust decisions.