# Why IndieJWT exists

> Decode a JWT locally, understand its clock claims, and keep verification separate from trust.

By turushan.

Published: 2026-09-03T00:00:00.000Z

Updated: 2026-09-18T19:56:44Z

Canonical: https://indiejwt.com/blog/why-indiejwt-exists/

JWTs are easy to decode and easy to misunderstand. A readable payload can look authoritative even
when nobody has checked its signature. IndieJWT exists to keep those two acts visibly separate.

Paste one compact token and the browser splits its three Base64URL parts. It shows the protected
header, the claims, and the signature bytes without sending the token to IndieJWT. It does not put
the token in the address bar, local storage, a cookie, or a public history.

The clock check follows the NumericDate rules in RFC 7519. It reads `exp`, `nbf`, and `iat` against
the device clock, shows the exact UTC values, and says when a claim is absent or malformed. It uses
no hidden clock-skew allowance.

Signature verification is a second action. IndieJWT gives the exact compact signing input and a
visitor-supplied asymmetric public key to browser WebCrypto. It supports the RS, PS, and ES SHA-2
algorithms listed on the tool. It refuses private keys and shared secrets. A JWKS URL is read
directly by the browser, without the JWT, cookies, credentials, or a referrer. The key host must
allow cross-origin reads.

A matching signature is useful evidence, but it is not a trust decision. An application still has
to decide which issuer and audience it accepts, which claims it requires, and which algorithms its
context permits. RFC 8725 explains why those checks matter.

IndieJWT will not turn into an account funnel. There is no card, premium plan, upgrade nag, saved
token list, or public inventory of what anyone checked. Analytics is currently off, so no tracker receives tokens or key material.

Read [signature verification and application trust](https://indiejwt.com/#does-a-valid-signature-mean-the-token-is-safe-to-accept). Use [IndieJWT](https://indiejwt.com/) to read a token locally and keep its clock claims separate from signature verification.

## Sources

- https://www.rfc-editor.org/rfc/rfc7519.html
- https://www.rfc-editor.org/rfc/rfc7515.html
- https://www.rfc-editor.org/rfc/rfc8725.html
- https://www.w3.org/TR/WebCryptoAPI/