DEV Community: chan

I rebuilt 4 dev tools so they stop uploading your data

chan — Fri, 05 Jun 2026 04:08:33 +0000

There's a quiet pattern in everyday dev work: the most convenient tool for a job
is a website you paste sensitive data into.

Need to read a JWT? → paste a production token into jwt.io.
Checking a Content-Security-Policy? → paste your security config into an online evaluator.
Sharing a payload in a bug report? → paste customer PII into an online redactor.

Each is genuinely useful — and each either uploads data you're trying to protect,
or makes you deploy first just to check a config. But none of these jobs needs a
server: they're parsing, checksums, and rule-based analysis that run fine in your
browser. So I rebuilt four of them to run locally and upload nothing.

1. jwtlens — decode, audit & verify JWTs

Decode the claims, run a security lint (alg:none, missing exp, HS↔RS
alg-confusion), and verify the signature client-side with the Web Crypto API —
HS/RS/PS/ES, with your own secret/PEM/JWK.

→ https://didrod205.github.io/jwtlens/ · npx jwtlens scan

2. csp-doctor — find the XSS holes in your CSP

Paste a policy and it flags 'unsafe-inline', wildcards, missing
object-src/base-uri, and the allowlisted CDN hosts that silently bypass CSP
(JSONP / hosted AngularJS) — nonce/strict-dynamic-aware, so a modern policy isn't
flagged for nothing.

→ https://didrod205.github.io/csp-doctor/ · npx csp-doctor scan

3. scrubpii — make a payload safe to share

Paste a JSON payload or log and get a redacted copy: emails, Luhn-valid cards,
JWTs, API keys, IPs. Pseudonyms keep referential integrity — the same value
maps to the same alias everywhere, so the redacted data is still coherent.

→ https://didrod205.github.io/scrubpii/ · cat payload.json | npx scrubpii redact

4. cookie-doctor — lint your Set-Cookie headers

Paste a Set-Cookie (or a curl -I response) and it flags missing
HttpOnly/Secure/SameSite, SameSite=None without Secure, and the
__Host-/__Secure- prefix rules — the violations that make a browser
silently drop your cookie, so logins mysteriously stop sticking.

→ https://didrod205.github.io/cookie-doctor/ · curl -sI url | npx cookie-doctor scan

How they're built (the part that makes "local-first" honest)

Each is a small TypeScript package with a pure, zero-dependency core that powers
both a CLI and the browser playground — same engine, same results. The CLI lets you
gate any of this in CI; the playground is just that core compiled for the web. The
only "server-ish" bit, JWT signature verification, runs on crypto.subtle in the
browser and node:crypto in the CLI (fun detail: JWS ECDSA signatures are raw
P1363, which WebCrypto wants natively but Node needs told explicitly).

All MIT, all on npm. If you maintain something similar, the takeaway is simply:
a lot of "paste it into our website" tools don't need to be websites.

Which dev tool do you wish ran locally? I'm collecting ideas.

You're probably leaking production tokens into jwt.io

chan — Fri, 05 Jun 2026 03:48:18 +0000

You hit a 401. You grab the JWT from a log line, drop it into jwt.io to read
the claims, and move on. I did this for years — until I realized that token was
often a still-valid production credential, and I'd just handed it to a
third-party website.

Even when a decoder swears "it stays in your browser," do you really want to take
that on faith for a prod token? You don't have to. Everything jwt.io does —
decode, inspect, verify the signature — can run entirely on your own machine.

Here's what's worth knowing, and a tiny tool that does it locally.

A JWT is three base64url chunks

header.payload.signature. Decoding is just base64url + JSON.parse — no secret
needed, which is exactly why "decode" should never require uploading anything.

const [h, p] = token.split(".").slice(0, 2).map((s) =>
  JSON.parse(atob(s.replace(/-/g, "+").replace(/_/g, "/"))));

The interesting part is everything around the decode.

The footguns a decoder should flag

alg: none. An "unsecured" JWT has no signature. If your server ever accepts
none, anyone can forge any token. This is the first thing to check, and it's a
one-line lint.

HS↔RS algorithm confusion. A server that verifies with the algorithm named in
the token (instead of a pinned one) can be tricked: an attacker takes your RSA
public key, signs a token with HS256 using that public key as the HMAC
secret, and your server happily verifies it. The fix is to pin the expected alg —
but a linter can at least warn when a token uses a symmetric alg.

Expiry hygiene. No exp means a leaked token is valid forever. A 30-day access
token means a 30-day blast radius. Missing aud/iss means the token isn't scoped
to your service.

Verifying a signature — in the browser

This is the part people assume needs a server. It doesn't. The Web Crypto API
(crypto.subtle) verifies HS/RS/PS/ES signatures client-side.

One gotcha worth the price of admission: ECDSA (ES256) signatures. JWS encodes
them as raw r || s (IEEE-P1363). Browser WebCrypto's ECDSA wants exactly that
format — but Node's crypto defaults to DER and needs dsaEncoding: 'ieee-p1363'.
Same math, two different serializations, and a classic source of "why won't this
verify" bugs.

const ok = await crypto.subtle.verify(
  { name: "ECDSA", hash: "SHA-256" },
  publicKey,          // imported from your PEM/JWK
  rawSignatureBytes,  // the P1363 bytes straight from the JWT
  new TextEncoder().encode(`${h}.${p}`),
);

No network. No upload. Your key never leaves the page.

The tool

I packaged all of this into jwtlens — decode, a security lint, and offline
verification (HS/RS/PS/ES with your own secret, PEM, or JWK).

Browser playground (nothing uploaded): https://didrod205.github.io/jwtlens/
CLI for CI / scripts: npx jwtlens scan "$TOKEN" (or verify with a key)
MIT, zero runtime deps in the core: https://github.com/didrod205/jwtlens

It's deliberately small and boring — a linter and a verifier, not a service. The
point is that none of this needs to be a service.

If you maintain an auth service, the most useful takeaway isn't the tool — it's:
pin your expected algorithm, set short exps, and stop pasting live tokens into
websites. The tool just makes the last one easy.

What would you want a JWT linter to catch that I haven't covered? I'm collecting
rules.