DEV Community: Ajiez

Stop Guessing at Auth Bugs: Decode the JWT First

Ajiez — Tue, 29 Sep 2026 14:03:28 +0000

Half the "works in Postman, fails in production" bugs I've debugged were readable in the token itself. Expired exp. Audience minted for a different client. A token from the wrong environment variable. The payload was sitting right there, base64url-encoded, one paste away — and instead of reading it, we were reading stack traces.

So here is the habit I've settled on: decode first, theorize second. It turns most auth mysteries into five-minute fixes.

The 30-second version

A JWT is three base64url segments joined by two dots: header, payload, signature. The first two are not encrypted — they are encoded, which means they are readable by anyone who holds the token. That is by design. The signature is the only part that proves authenticity; the payload merely claims.

The fastest decode is a browser tool, because it keeps the token on your machine (a debug token with a live access_token in it has no business being pasted into a random web form). I built a JWT decoder that runs entirely client-side: paste, read the header and payload as formatted JSON, see the expiry status at a glance. Thirty seconds, zero network.

Once you can read tokens fluently, five claims decide most real-world outcomes:

Claim	Meaning	What catches people
`exp`	Expiry, Unix seconds	The token was dead the whole time; clocks and "it worked yesterday" lie
`iss`	Who issued it	Expected Auth0, got `https://accounts.google.com` — wrong env var
`aud`	Who it's for	Minted for a different client_id than the one sending it
`scope`	What it may do	The integration promised `read:orders`, the token says otherwise
`sub`	Who it is	A user id where you expected a service account, or vice versa

If you want the full walkthrough — the field-by-field reasoning, the failure modes, the "only part of the token got copied" classics — I wrote a longer guide on how to decode a JWT token, and it is the reference I'll paraphrase below.

Access token vs ID token: same dots, different jobs

Here's the triage that took me embarrassingly long to internalize. People paste two very different tokens into a decoder and expect similar answers.

An access token is the thing you send as Authorization: Bearer .... It may be a JWT or an opaque string. If it decodes into three parts, its exp, scope and aud tell you what it can do and until when.

An ID token comes from an OIDC login flow. It is always a JWT, but it describes the user — email, name, sub — not permissions.

Three-second triage table:

Payload contains	You're holding	Check
`exp`, `scope`, short `sub`	access token	Is `exp` past? Is `scope` what the integration promised?
`email`, `name`, `aud` = your client_id	ID token	Does `aud` match your client? The `nonce` you sent?
No dots, random string	opaque token	Nothing to decode — resolve it at the issuer's introspection endpoint

The classic bug this catches: sending the ID token to your API because it was the token lying around after login, then wondering why the API rejects it. The API wanted the access token. The payload told you which one you had the entire time — that access token vs ID token comparison is worth bookmarking the next time an integration "randomly" 401s.

What the libraries actually do (four languages, one pattern)

Every serious JWT library separates decoding from verification. Knowing the exact shape of that separation in your language saves an afternoon:

Node (jsonwebtoken) — jwt.decode(token) decodes without verifying: the direct equivalent of pasting into a browser tool. jwt.verify(token, secretOrPublicKey) checks the signature and throws on failure, with the reason named in the error (TokenExpiredError, JsonWebTokenError). Decode to inspect, verify to trust.

Python (PyJWT) — inspection is jwt.decode(token, options={"verify_signature": False}). Verification demands the algorithm explicitly: algorithms=["RS256"]. That friction is deliberate — it exists to prevent the alg: none downgrade class of bugs, where a crafted token declares no signature and a lazy verifier obligingly skips the check.

Go (golang-jwt) — parsing and validation are separate calls. The interesting part for multi-tenant systems: key lookup happens by the token's kid header, so the practical pattern is decode-first (read kid, route to the right tenant's key), then validate.

Java (jjwt) — parseClaimsJwt() handles unsigned parsing; anything signature-checked wants the key at parse time.

Four ecosystems, one philosophy: verification is the loud, default path; decoding is the quiet, explicit one. When you find yourself fighting the library to "just decode the thing," that's not friction to work around — it's the library telling you which operation deserves suspicion.

Decoding is not verifying

The one sentence that belongs in every code review: a decoded payload is a claim, not a fact. Anyone can mint a token that says {"role":"admin"}. The signature is the only part that proves who issued it and that nothing changed in transit.

And the red flag to say out loud: if a token's header reads alg: none and the signature segment is empty, it is asking to be trusted with zero proof. Production systems reject it. Debuggers treat it as a finding, not a curiosity.

The habit, compressed

Decode before you theorize. Check exp, iss, aud, scope in that order. Know whether you're holding an access token or an ID token before you blame the API. Trust signatures, not payloads. And when a token misbehaves, paste it somewhere safe before pasting it into a search engine — the answer is usually in the middle segment.

I build Ajiez, a collection of free, local-only browser tools — the JWT decoder above is one of them. Everything runs client-side: your tokens, keys and files never leave your machine.

108 Keywords Later: How I Chose What Tutorials to Write for a 101-Tool Site

Ajiez — Mon, 14 Sep 2026 23:41:01 +0000

Most content roadmaps are vibes with a spreadsheet skin. You list what you feel your audience needs, ship it, and six months later Search Console quietly informs you that nobody searched for half of it. When I finished building Ajiez — a collection of 101 free browser tools — I had 37 tutorials to plan and exactly zero interest in guessing again. So I pulled real search data first and let it overrule me. It did, repeatedly. Here's what the numbers said, and the small-site workflow you can copy.

The data pull

Bing Webmaster Tools exposes an API endpoint that returns weekly impression counts for any keyword, by country and language. It's the quiet cousin of Google's keyword tools: free, boring, and — crucially for a small site — good enough to rank directions even when it can't promise volumes. The usual caveat applies: Bing serves roughly a quarter to a third of Google's search volume in my niches, so I treat every number as a compass reading, not a forecast.

I drafted 108 candidate keywords across my tool categories — finance, PDF, images, dev utilities, text — and queried them all for the US market, English, exact match. Every request succeeded. Seventy-one keywords came back with data. Thirty-seven came back with nothing.

That "nothing" is worth pausing on, because it's the most misunderstood output in keyword research. An empty response doesn't mean zero people search for the term. It means Bing has no measurable ad inventory for it — no impressions recorded. For a tiny site, that's still actionable: these are words where even Bing's demand signal is too thin to plan around. Park them; don't build on them.

What the data changed

The guide I almost didn't write. My assumption was that JSON tooling was my biggest content gap — developers break JSON constantly. The data said otherwise: "diff checker" showed 2,841 weekly exact-match impressions, nearly four times "json validator" at 790. Comparing two versions of a text is a far more universal act than debugging a config file: contract redlines, essay revisions, pull-request descriptions. So the first guide out of the gate was how to diff two texts, pointing at a text compare tool that runs entirely in the browser. The assumption I started with would have spent my best slot on the fourth-best topic.

Same field, different wedge. "Json formatter" pulls 3,946 weekly impressions — and an incumbent site has owned that head term for a decade. Fighting it head-on is a content strategy for sites with domain authority I don't have. But "json validator" at 790 is a different intent: not "make this pretty" but "find what's broken," ideally with a line number. That intent shapes a different page — a "why your JSON breaks and how to read the error" guide that pairs with a formatter and validator that flags the failing line. Volume told me the field was alive; the split between two nearly identical keywords told me where the opening was.

Aggregating families beats staring at single words. "Amortization schedule" alone showed 1,873 weekly impressions. But four related phrasings — the schedule itself, "with extra payments," "extra payment calculator" variants — added another ~230. Families matter because one good guide captures the whole cluster, and the family total told me this was the largest finance content opportunity in my entire dataset. A mortgage amortization guide with worked extra-payment examples went near the top of the queue.

Tool queries are content opportunities too. "Character count" pulls 1,047 weekly impressions, locked up by counters that answer the mechanical question and nothing else. But the interesting question behind that query is platform rules: why does any link on X cost exactly 23 characters, why does a Chinese SMS split at 70 instead of 160, why does Google truncate your 58-character title anyway? That's a cheat sheet, not a tool feature — so I wrote one, next to a plain word counter for the mechanical job. The character limits cheat sheet targets the question the head-term sites were ignoring.

The finding that rewrote my positioning

Here's my favorite result, and it was a negative one. My site's whole differentiation is that files never upload — everything runs client-side. Naturally, I queried "no upload," "without uploading," "offline tools" and eight similar phrasings. Eleven seed keywords, zero data. All of them.

The conclusion isn't that privacy doesn't matter. It's that nobody searches for it. People search for the task ("compress PDF"), then choose between results — and "your file never leaves this tab" is what wins them at the moment of choice. That reframed privacy from a keyword strategy (which would have wasted a page on it) into a conversion message that belongs in title tails and trust bars across every page I already have. Arguably the most valuable thing 108 API calls bought me was the death of one bad page idea.

The workflow, distilled

List candidate keywords from your own features first — every tool you've built implies five to ten queries it could answer.
Pull exact-match weekly impressions for all of them in one batch. Any free source beats none; Bing's API is unglamorous and sufficient.
Sort by family, not by word. Aggregate phrasings that one page could satisfy.
Read the splits inside a field. Formatter-vs-validator, schedule-vs-extra-payments — near-duplicate words with different intents are where small sites find openings the incumbents left.
Honor the empty responses. Zero data means don't build; log it and move on.
Separate data from inference. My volume numbers are measurements; my competition calls are me reading result pages with my eyes. I label them differently in my notes, and this post does too.

My tutorial roadmap is now chosen, sequenced, and justified by numbers I can re-run any afternoon. Some of it will still flop — data shrinks the odds of a bad bet; it doesn't erase them. But "I wrote this because 2,841 people a week ask this question and the current answers don't run locally" is a far better reason than a hunch.

If you want to see where the workflow landed, the diff guide and the rest of the stack are live on Ajiez — 101 tools, everything client-side, no accounts. And if you've got your own small-site keyword workflow, I'd genuinely like to hear what your empty responses taught you.

AI tools that never upload your files: I only trust calculators and cutouts that run in my browser

Ajiez — Sat, 12 Sep 2026 15:45:40 +0000

Every few months a new online tool goes viral, and every few months someone discovers that the "privacy-friendly" PDF editor they just used shipped their tax documents to a server farm. I got tired of wondering, so I started applying one simple test to every tool I use: open DevTools, go to the Network tab, and watch what happens when I feed it a file.

For most tools, the answer is sobering. The file leaves the tab before the first preview renders.

A browser in 2026 is an absurdly capable runtime. WebAssembly runs real ML models. Canvas and WebCrypto handle images and encryption natively. Which means a whole class of tools — the kind that used to demand an upload — can now run entirely on your machine, and the only reason many still don't is that uploading your file is a better business model than respecting it.

The two-minute privacy test

Try this on any tool site:

Open DevTools → Network tab.
Drop your file in.
Watch for a request with a body.

If the list stays quiet while the tool works, everything happened locally. If a POST flies off to an API the moment you click — you were the product, or at least your file was.

This test is why I ended up building my daily toolkit around Ajiez, a collection of 101 free browser tools. The background remover is the flagship demo: a real segmentation model (U2Net, ~5 MB) downloads once into the browser cache and every cutout after that runs on-device. Cut out a photo of your kid, your ID, a client's product shot — nothing uploads, because there is no upload path in the code at all. Disconnect your Wi-Fi and it still works. That's not a privacy policy; that's an architecture.

The calculators nobody thinks about

Here's the part that surprised me: the tools that leak the most sensitive data are the boring ones. People paste salary numbers into "paycheck calculators" hosted by lead-gen farms, feed their mortgage details into refinancing funnels, and paste invoice totals into sites that exist to sell their data to lenders.

That's why I point anyone doing money math at a calculator cluster that runs the same way as the cutout tool: entirely in the tab. The finance calculators hub covers the whole "money questions" stack — take-home pay under 2024 federal rules, the self-employment tax freelancers always underestimate, credit card payoff timelines that show why minimum payments take 56 years, retirement projections with the 4% rule spelled out. The math is plain JavaScript running against your inputs; the numbers have no way to leave.

There's an extra benefit beyond privacy: the tool works when the site doesn't care anymore. No rate limits, no signup walls, no "you've used your 3 free operations today." A browser-local tool can't meter you, because there's no server to do the metering.

What browser-only can't do

To be fair about the trade-offs: a 5 MB WASM model is not a 5 GB datacenter model, so the background remover is good, not magical — complex hair edges lose to server-side monsters. And anything that genuinely needs fresh data (live currency rates, say) still needs a network call somewhere. The honest framing: for a huge slice of everyday tasks — cutouts, OCR, PDF surgery, every calculator under the sun — local execution is not a compromise anymore. It's just better defaults.

Try the test yourself

The next time a tool asks for a file or a number, spend the two minutes. Open the Network tab first. Tools that pass it quietly deserve your bookmarks; tools that don't deserve a second thought.

(I keep the whole toolbox at ajiez.top — no account, no uploads, and the DevTools test above will confirm both claims.)