DEV Community: tomcate

I Published 24 Articles in 5 Days. Here's What Actually Moved — and What Took 3 Days to Show Up.

tomcate — Sat, 10 Oct 2026 01:20:29 +0000

title: "I Published 24 Articles in 5 Days. Here's What Actually Moved — and What Took 3 Days to Show Up."
published: true
tags: seo, contentstrategy, webdev, indiehackers

description: "A solo dev's content sprint on a 172-tool site: 24 posts in 5 days across two languages, a 38-position jump in Google rankings, a traffic record — and the honest numbers on what lagged (GSC's 2-3 day delay, Baidu's 10-URL daily quota, and the silent MDX build failure that ate a post)."

Two months ago my side project — ToolVault, 172 browser-local developer tools — had the classic tool-site problem: utility traffic, no depth. People came, used the formatter, left. Google had noticed the same thing: our average position was 52.7. Page three of the search results, which is the same as not existing.

So I ran a content sprint. Not the "write every day" kind — the engineering kind, with a backlog, a bilingual pairing constraint, a per-day URL quota on the biggest search engine in my market, and a build pipeline that fights back. This post is the honest numbers: what moved immediately, what took three days to register, and what quietly broke.

The shape of the sprint

Five days, 24 articles, two languages each — 48 files. Three clusters:

Post-quantum cryptography (14 posts): migration checklists, ML-KEM internals, passkeys, Ed25519, HKDF — a deliberate bet on a topic where 2026-2028 regulatory timelines are creating search demand faster than supply
China compliance (6 posts): MLPS 2.0, PIPL impact assessments, generative-AI filing checklists — dense, checklist-heavy, almost no competition from real tool sites
GEO (6 posts): making sites legible to AI search, robots.txt decisions for AI crawlers, llms.txt

Every post follows the same template: a real problem, a working checklist or table, an implementer's note with details only the person who built the thing knows, and cross-links into the tool pages.

What moved immediately

Direct traffic to fresh content. The PIPL impact-assessment post hit the site's top-10 pages the day it shipped — 18 visits from nowhere, which told me the search demand was real and the internal linking was doing its job before Google even noticed.

The spider economy. Baidu's crawler went from ~215 to ~280 hits/day across the sprint — new content doesn't just wait for organic discovery when you're pushing URLs through their API. Speaking of which:

The quota war nobody warns you about

Baidu's URL submission API allows 10 URLs per day for a site our size. Ten. We had 20 new posts' worth of Chinese URLs on day one of the sprint. That constraint reshaped the whole distribution plan: explicit URL lists over sitemap-driven auto-push (which had previously burned entire days' quotas on alphabetically-first tool pages), a next-morning ritual of pushing the highest-value ten, and English URLs excluded entirely (they go to IndexNow/Bing instead — different ecosystem).

If your market includes China, budget the quota into your content calendar. It's a strange but real rate limit on your distribution.

What took three days to show up

Google Search Console operates on a 2-3 day lag. The sprint started on a Friday; the first GSC evidence of the 146 deepened pages (an earlier content pass, same sprint family) arrived Monday. And it arrived spectacularly: average position 52.7 → 14.1 in a week, with the page-level impressions list composed entirely of deepened posts.

The lesson that took me an embarrassing amount of time to internalize: you cannot evaluate a content batch on day one. Not on traffic (internal links only carry you so far), not on GSC (the lag). The earliest honest read is day three, and the real read is day seven. Plan your metrics review cadence around that, or you'll either panic or celebrate early, both wrongly.

What quietly broke

The scariest part of the sprint wasn't the writing. It was this: one post silently vanished from the production build.

The cause: MDX parses < followed by a letter or digit as JSX. A perfectly innocent sentence — "lifetimes under 10 years are mostly fine" written with a literal <10 — threw a compile error that the build logged without failing the build, and the post simply didn't exist at its URL. A 404 where content should be.

We caught it only because the deployment checklist requires per-post curl checks: HTTP status plus a feature phrase grep for every new URL, every deploy. The fix was rewriting the sentence in prose ("under 10 years"). But the meta-lesson stands: static-site content pipelines fail silently, and "the build passed" is not "the content shipped." Verify per artifact, not per build.

(That same week the build also rejected a post title because the OG-image font subset lacked one Chinese character. Content pipelines are pipelines.)

The scoreboard

Signal	Before	After 5 days
Published posts	147	171
GSC average position (7-day)	52.7	14.1
Human UV (server logs, daily, bot-filtered)	~550	1,104 (record)
Baidu spider hits/day	~215	~280
PQC post traffic	0	top-5 page within 3 days

The honest caveats: correlation isn't attribution — the sprint rode a holiday traffic peak, some of the position jump is the older deepening batch landing, and one day's record UV proves nothing by itself. But the composition of the traffic changed in a way raw numbers don't show: search-sourced visits to deep content instead of drive-by tool usage.

What I'd do differently

Write the distribution plan with the content plan. The Baidu quota and the bilingual pairing constraint (our sitemap generator refuses unpaired zh/en posts — a 404-prevention rule that also once blocked a deploy for an hour) should shape the batch sizes from day one, not be discovered mid-sprint
Automate the per-post verification harder. Every deploy should assert N new URLs × 200 × feature phrase, mechanically. We do it by script now; it should have been that way before the 404
Trust the three-day rhythm. Publish, verify rendering, wait 72 hours, then look at data. Anything else is vibes

Try it

The sprint posts are live on ToolVault — the PQC cluster starts with a migration checklist, and the compliance series is deeper than anything I've found from a tool site. The series covers how the 100%-local architecture makes all of this a one-person operation.

And if you're running a tool site with thin content: the deepening math is unglamorous and it works. Position 52 to 14 in a week is not a growth hack. It's table stakes arriving late.

A "Review-Safe" Cookie Banner Blinded 98% of My Analytics for 36 Hours (Postmortem)

tomcate — Sat, 03 Oct 2026 01:14:28 +0000

On September 30 we shipped a cookie consent banner and called it review-safe in the deploy note. For the next 36 hours, it silently uninstalled our analytics from 98% of our visitors — and the scariest part is how reasonably every individual decision looked along the way.

This is a postmortem of a self-inflicted outage that never threw an error, never returned a 500, and never fired an alert. The outage was invisible by construction, because the thing it broke was the instrument you would use to notice it.

The setup

ToolVault is my side project: 172 developer tools (JSON, hashing, JWT, PDF, image work) that run entirely in the browser — no uploads, no accounts, no backend except one audited proxy route. Like every hobby site with real traffic, it monetizes (eventually) with ads, and ad programs want to see a consent flow. So the to-do was legitimate: ship a GDPR-style cookie banner before applying for ad review.

The implementation was, by every checklist we had at the time, clean:

A banner with Accept all / Reject all / Essential-only choices
Consent state persisted, reject semantics honored, page reloads on change
AA-contrast UI, no layout shift, no route changes, no page structure changes
Deploy note: "review-safe — no structural changes"

And one behavioral decision buried in the middle of it: analytics and ad scripts are injected only after the visitor clicks "Accept all."

That is the strictest, most privacy-conservative model — opt-in. If you were grading this change for compliance, you would give it extra credit.

The silence

Here is the number nobody on the team had internalized: about 98% of visitors never click any button on a consent banner. They scroll past it, or dismiss it mentally, or have trained themselves to ignore anything banner-shaped years ago. This is banner blindness, and it is well-documented in the UX literature — it just never appears in the compliance checklist.

With opt-in gating, "never clicks" means "never loads the script." Not "loads it later." Not "loads it with reduced granularity." The script simply does not exist for that pageview.

The next day, GA4 reported 8 users. The day before the deploy: ~115.

And the server access log, which listens to no consent banners, counted 446 unique human visitors that same day.

Signal	Sept 30 (before)	Oct 1 (opt-in gate live)
GA4 active users	~115	8
Server log, unique humans	—	446

Analytics coverage didn't dip. It fell off a cliff to ~2%, on the healthiest traffic day of the week.

Why it took 36 hours to notice

Day 1, the drop got read as a reporting artifact. GA4 shows a "processing incomplete" badge on recent days, and 8-vs-yesterday is exactly the kind of number a broken report card would explain away. The badge was real — GA4 reports genuinely do lag — and that's what made it such an effective camouflage. A lie is easy to catch; a technically true status message that stops applying at the exact wrong moment is much harder.

The deeper failure was structural: we had exactly one instrument, and the outage broke that instrument. A single-channel monitoring setup cannot detect the death of its own channel. It's the monitoring equivalent of the light in the fridge — everything looks fine from inside.

Day 2 morning, the cross-check finally happened: 446 humans in nginx vs 8 users in GA4 is not a reporting lag, it's a 98% disagreement. From there the diagnosis took minutes, because each step only had one possible next step:

curl the homepage → no gtag.js in the HTML
Search the codebase for what conditionally renders analytics → the new ConsentScripts component
Git timeline → shipped 20:03 the night before, labeled review-safe

Deploy the fix at 09:17. Realtime shows a live visitor within the minute. Total time from first blind pageview to fix: ~36 hours, of which nearly all were "nobody knew."

The fix: opt-out, and why it's still compliant

The repaired model is opt-out: analytics loads by default; an explicit click on "Reject all" (or "Essential only") stops it, immediately and persistently. Visitors keep full control — the reject path is honored more carefully than before, down to reloading the page so no already-loaded script survives the choice.

Opt-out-with-real-rejection is the model most of the industry actually runs (and what many regulators effectively expect for analytics-grade, non-personalized usage). Pure opt-in for measurement scripts sounds saintly and, combined with human banner behavior, functions as an analytics kill switch. Compliance is not a slider where "most restrictive" always means "most correct" — it's a trade-off that has to survive contact with how people actually behave.

One more lesson shipped with the fix, free of charge: our CDN caches HTML with s-maxage=3600, stale-while-revalidate=86400. That means after the fix deployed, the first visitor to each cached URL still got the old consent-gated page, and only triggered a refresh for the next one. With 172 tool pages and 140+ blog posts of long-tail traffic, stale copies of the blind page kept serving for up to 24 hours. "Fixed" and "effective" are different timestamps, and the distance between them is your cache TTL × your URL count.

The counterfactual that made us take it seriously

Here's the part that turned this from an embarrassing anecdote into a process change. At the time of the incident, the ad program hadn't approved the site yet — zero ads were running — so the revenue impact was exactly ¥0.

If the same gate had shipped two weeks later, with ads live at ~1,000 visitors/day: 98% coverage loss on ad inventory, at typical RPMs, is roughly ¥9,800/day ($1,400). And there is no alert for "ads didn't render" — you'd discover it in the weekly review, 5–7 days in, at ¥50k–70k. A "compliance improvement" that quietly costs a month of revenue.

Zero loss by luck is not zero risk. The only reason this was free is that we hadn't yet earned the ability to lose money.

Four guardrails we now run

Analytics smoke test after every deploy (mandatory, 60 seconds). Open any tool page, open GA4 Realtime, see your own visit within 30 seconds. If you can't, you roll back before touching anything else. This single habit would have caught the outage at 20:05 instead of two days later.
Cross-channel validation, daily. Analytics users vs. server-log unique humans. Divergence over 50% must be investigated that day, and "GA4 processing is lagging" is no longer an acceptable closing statement for a 98% gap.
Any change that touches when scripts load is a revenue-pipe change. The deploy note for anything touching consent, analytics, or ad loading must carry one explicit line: who can still be measured, and who can't. "No structural change" describes the diff, not the behavior.
Compliance changes get a business-impact review, not just a legal one. Coverage of measurement, coverage of ad inventory, revenue at risk — written down next to the AA contrast check. Our postmortem's counterfactual math (above) is the template.

Try it

The site that survived its own consent banner is ToolVault — 172 developer tools that process everything locally in your browser, which is also why it can run an honest default-on analytics setup: there's no upload pipeline to consent to in the first place.

The rest of the series covers the 100%-local architecture, auditing the one route that broke that promise, and what six frontier models saw (and missed) when auditing the lying code.

And the takeaway I'd tattoo on the inside of every deploy note: if a change gates when scripts load, it doesn't matter that it "only touches compliance" or "only touches UI" — it just changed your revenue pipes. Smoke-test the pipes.

I Turned a Real Security Incident Into a Benchmark. 6 Models Audited the Code That Lied.

tomcate — Thu, 24 Sep 2026 13:41:05 +0000

Three weeks ago I audited a server-side proxy route in my own product and found that its code had been lying to me. The comments confidently described a security posture — validate every target, strip credentials, cap responses — while the implementation quietly leaked past all of it. I fixed the bugs, wrote up the incident, and then realized I was sitting on a better question:

If a human auditor was initially fooled by self-confident code, would AI models be fooled too?

So I turned the incident into a benchmark on Kaggle, ran six frontier models against it, and the results falsified my hypothesis in an interesting way. This post is that experiment — built and submitted for the Kaggle Benchmarking Challenge.

The benchmark: one real file, two variants

The test subject is proxy.ts, a real production file from ToolVault (my browser-local developer tools site — the one server route it has). It forwards user-directed HTTP requests to third-party targets, which makes it exactly the kind of code where SSRF matters.

I planted nothing. The file contains seven real defects that a human adversarial audit later confirmed, including two critical SSRFs:

Redirect following without re-validating targets (a public domain can 302 the proxy into 169.254.169.254)
A DNS-rebinding TOCTOU: the validation does one DNS lookup, the connection does a second
Rate limiting keyed on the client-forgeable x-real-ip header
Proxy control headers (x-proxy-insecure: 1, ...) forwarded to third-party targets
Unbounded response buffering (post-hoc "truncation")
A body-limit rejection surfacing as an unhandled 500
HTTP 310 — a real legacy status code — reused as a synthetic "too many redirects" sentinel

Then I created two variants of the same task on Kaggle Benchmarks: the code with its original confident comments, and the identical code with every comment stripped. The task prompt asks for a security audit with severity, concrete attack scenario, and minimal fix per finding. A strict judge model grades each audit: a defect counts only if the mechanism is named — "there might be some SSRF" scores nothing. The score is defects found, minus half a point per hallucinated finding.

Why the two variants? My hypothesis going in: the confident comments ("strip hop-by-hop headers", "credentials are never forwarded") would anchor the models, and the stripped variant would score higher.

The models

Eight models across six families, flagship through open-weights: Claude Opus 5, Claude Sonnet 4.5, GPT-5.5, GPT-6 Astra, Gemini 3.8 Flash, DeepSeek-R1, GLM-5, and Gemini 3.5 Flash-Lite. (Gemini 3.8 Flash stayed rate-limited by the model proxy through both rounds, so it does not appear in the completed matrix.)

Result 1: the ceiling is four out of seven

The best score of the entire benchmark is 4/7, achieved with mechanism-level credit. The distribution:

Model	With comments	Comments stripped
Claude Sonnet 4.5	4.0	2.0
GLM-5	4.0	3.5
GPT-5.5	3.5	2.0
Claude Opus 5	2.5	—
DeepSeek-R1	—	3.5
Gemini 3.5 Flash-Lite	2.0	—
GPT-6 Astra	1.0	1.5

The two critical SSRFs were found by most models — genuinely good news. But defect #6 (an error-handling gap) was named by almost nobody with a correct mechanism, and defect #7 was found by zero models out of eleven completed audits. A tiny wrongness — reusing a real HTTP status code as a sentinel — is invisible to every frontier model that looked at it. Humans miss it too, honestly. That is precisely why it survives in production code.

Result 2: mentioning is not finding

The sharpest signal came from comparing what models wrote against what they were credited for. GPT-6 Astra's audit touched five of the seven defect areas — redirect risk, control headers, buffering, the error path — and was credited for exactly 1.0. GPT-5.5's stripped-variant audit name-checked six areas and earned 2.0.

This is the gap between a security audit that reads well and one that bites. The models produce beautifully organized reports where each section gestures at a vulnerability class. The grader — like a real adversarial reviewer — demands the mechanism: which line, which second DNS resolution, which header. Under that standard, fluency collapses to nothing. If you use LLMs for code review, this is the thing to worry about: not that they refuse to find bugs, but that their findings are frequently gesture without mechanism, and it takes a skeptical reader to notice the difference.

Result 3: my hypothesis was wrong — the comments helped

The paired results flipped my prediction. Three of four models with completed pairs scored higher with the comments present than without (mean delta +0.88):

Claude Sonnet 4.5: 4.0 with comments vs 2.0 without
GPT-5.5: 3.5 vs 2.0
GLM-5: 4.0 vs 3.5
GPT-6 Astra: 1.0 vs 1.5 (the one exception)

My best reading: the comments did not blind the models — they oriented them. A comment like "the redirect follows Postman behavior" tells the auditor where the author's intentions live, and auditing intentions against implementation is exactly where the defects hide. Stripped of comments, the models had less scaffolding for suspicion, not more.

Honest caveats: four paired models is a small sample, the with-comments variant is also the longer text (the two variables are not fully separated), and one model was dropped entirely for proxy rate limits — infrastructure bias is real in benchmarks, including mine.

What I would measure next

Three follow-ups, in order: (1) same variants, but ask models to fix the code, then diff the fixes against the human patch — audit-accuracy vs repair-accuracy are different skills; (2) a third variant where the comments actively misdescribe the code (claiming validation that does not exist), which is the stronger version of the lying-code question; (3) more models on the exact same task — the benchmark is public, and every additional model makes the picture less anecdotal.

Try it

The benchmark is public on Kaggle — audit the lying proxy yourself:

The proxy that came out of the human audit — with per-hop re-validation, connecting only to validated IPs, Host/SNI pinned to the original domain — is live in the API tester on ToolVault. The rest of the series covers the 100%-local architecture behind it.

And the takeaway I keep re-learning: the scariest code is not the code with no comments. It is the code whose comments sound exactly like your security checklist.

My Site Has No Backend — Except One Route. Auditing It Found 4 Real Holes.

tomcate — Thu, 24 Sep 2026 10:53:20 +0000

ToolVault is 172 developer tools that run entirely in your browser. No backend, no database, no uploads — that is the whole pitch. But there is exactly one server-side route: a proxy that lets the API tester reach endpoints whose CORS policy would block a direct browser call. One day I read its code the way an attacker would. This post is the four holes I found, and the fixes that survived testing against live redirector services.

Hole #1: the redirect that walked past the bouncer

The proxy validated its target before connecting: resolve the host, refuse private and reserved IPs. Solid — except HTTP redirects exist.

attacker.com  →  302 Location: http://169.254.169.254/latest/meta-data/

My redirect loop followed Location and fired the next hop without re-running the validation. One DNS lookup at the door, then the guest list stopped mattering. Any public domain I controlled could pivot the proxy to cloud metadata, localhost services, or the internal network — the classic open-proxy escape.

The fix is one line of discipline, applied per hop: every redirect target goes through the same validation as the first. Not "validated once at entry" — validated at every hop, because every hop is a new request to a new host.

Hole #2: two DNS lookups means you checked a different host than you connected to

The deeper version doesn't even need a redirect. The code did this:

const records = await lookup(host);      // check: is any record private?
// ...later...
https.request({ hostname: host, ... });  // Node resolves host AGAIN

Two independent resolutions. An attacker controlling the authoritative DNS answers the check with a public IP, then answers the real connection with 127.0.0.1. The validation passed; the connection went somewhere else. This is DNS rebinding, and any check-then-connect pattern written as two lookups is vulnerable to it.

The fix that kills the whole class: validate what you connect to, then connect to what you validated.

const ip = await resolveAndValidate(url);   // one lookup, checked
https.request({
  hostname: ip,                             // connect to the validated IP
  headers: { ...headers, host: url.host },  // Host header stays the domain
  servername: url.hostname,                 // TLS SNI stays the domain
});

No second resolution exists, so there is no gap to race. The Host header and SNI still carry the original domain, so virtual-host routing and certificate validation behave exactly as before — verified against a public echo service that reported host: postman-echo.com while the socket connected to an IP.

Hole #3 and #4: the client-side bugs an audit caught for free

Digging through the surrounding code found two bugs that no test had caught:

btoa with a non-Latin1 password crashed the whole page. Basic auth preview ran btoa(user + ":" + pass) during render. A Chinese character in the password field — not exotic for a Chinese-locale site — throws InvalidCharacterError, and since it executed in the render path, the entire tool went white. The digest-auth path three components over already used the UTF-8-safe pattern; nobody had unified them. One shared toBase64Utf8() helper closed it.

A file upload that silently sent a filename instead of the file. The form-data editor updated a row twice in a row — set the File object, then set the display name. Both updates were computed from the same stale props closure, so the second call rebuilt the row from the pre-file state and erased the first. row.file was always null by the time the request was built; the multipart body carried the filename string. No error, no warning — the upload just didn't work, ever.

Both fixes are one-liners once diagnosed. The lesson isn't the bugs; it's that they survived 1,246 passing tests. Unit tests verify the code you thought to write; an adversarial read asks what the code actually permits.

The quiet ones: rate-limit trust and control headers

Two more, cheaper but worth naming:

The rate limiter read the client IP from x-real-ip — a header any client can set. Rotate the header, get a fresh bucket, defeat the limit entirely. Now the header is only trusted when the TCP peer itself is our own infra (nginx on the host, the Docker bridge): a public client cannot spoof its source address, so a private-range peer is trustworthy by physics.
Every x-proxy-* configuration header (including the "skip TLS verification" flag) was being forwarded to third-party targets. Your debugging flags leaking to someone else's API server is its own genre of incident. Strip the whole prefix before forwarding.

The checklist, compressed

If you run any server-side fetch of user-influenced URLs:

Validate every hop — the entry check and the redirect check are the same check.
Connect to the validated IP — one resolution, Host/SNI pinned to the domain. This deletes rebinding instead of racing it.
Trust forwarded-for-style headers only from provable infra peers.
Strip your own control headers before they reach the outside world.
Stream with a hard cap — buffer a response of unbounded size and one hostile URL is an OOM; destroy the upstream socket at the limit and flag truncation.

And the meta-lesson: the proxy had comments describing excellent security. Comments are not capabilities. The audit that mattered was reading the code as "what can I make this do", not "what does it say it does" — and then verifying the fixes against a live redirector (https://postman-echo.com/redirect-to?url=http://127.0.0.1/... now dies with "forbidden address", which is the most satisfying log line I have read all week).

The proxy that does all of this correctly is part of the API tester on ToolVault — client-side by default, one hardened route when you need it. The rest of the series covers how the 100%-local architecture works and why AI crawlers love it.

Making a Tool Site Legible to AI Assistants: GEO in Practice

tomcate — Tue, 22 Sep 2026 10:38:22 +0000

There is a new front door on the web, and it does not have a search box. When someone asks ChatGPT, Perplexity, or Claude for "a tool to convert HEIC photos", the assistant picks from what it can see. If your site is invisible to that process, you are not in the consideration set — regardless of your Google ranking.

This post is the practical checklist we run on ToolVault (166 browser-local developer tools), with the actual crawler numbers from our logs and the mistakes that cost us rework.

First, the uncomfortable physics: AI crawlers do not run JavaScript

GPTBot, ClaudeBot, PerplexityBot and friends fetch HTML and read. They do not hydrate React, they do not execute your bundle, and they will not wait for your client-side rendering to finish. A JavaScript-only tool page arrives at the model as an empty shell.

Our site is statically exported (998 pre-rendered pages), which made this a non-issue — but if your content lives behind client rendering, that is item zero on this list. Test it the honest way: curl your page and look for the actual content in the HTML. Not "view source in DevTools" — the raw bytes a crawler gets.

llms.txt: useful convention, fatal if hand-maintained

llms.txt is the emerging convention for telling AI agents what your site offers. Ours covers the tool catalog, the privacy model, and per-category entry points, in both English and Chinese.

The lesson that cost us a month: generate it at build time from your single source of truth, never hand-edit it. Our first version was hand-written. It rotted in the exact ways hand-maintained files always rot: duplicate section titles after a copy-paste, tool counts drifting from reality ("130+ tools" when we had 144), a Chinese edition that never existed because nobody remembered to add one. An llms.txt that misdescribes your site is worse than none — it confidently teaches models the wrong thing.

Now a build step regenerates it from the same registry that renders the site. Counts are always exact; the file cannot drift because nobody edits it by hand.

robots.txt: decide, explicitly, who you let in

The default posture many sites discover they have (blocking everything unrecognized) or the opposite (allowing everything silently) are both decisions — just unmade ones. Ours is explicit:

User-agent: GPTBot
Allow: /

...for every AI crawler we know about, alongside the standard search bots. This is a values call: we want assistants to be able to recommend local-first tools accurately, because the privacy story is the product. A paywalled-content site might reasonably reach the opposite conclusion. Make the call on purpose.

The reward loop is real, and measurable

After the crawler allowances went live, our nginx logs filled up. The current steady state: 400-1000 AI crawler requests per day — GPTBot, PerplexityBot, ClaudeBot, Amazonbot, PetalBot — systematically walking the catalog. And then the loop closes: referral traffic from perplexity.ai and chatgpt.com starts appearing in the same logs. Small numbers yet, but the direction is established: assistants that can read your site will cite it, and their users click through.

We also push every new page through IndexNow (Bing's protocol, which ChatGPT Search partly sits on). It costs one POST request and removes the discovery delay for the engines that honor it.

What did not matter (for us, so far)

Structured data beyond the basics: we ship standard FAQ and tool schemas, but there is no evidence AI assistants consume JSON-LD preferentially over readable HTML.
Per-prompt optimization tricks: the content that models quote is the content that answers the question plainly. Our per-tool FAQ sections — written for humans — are what surfaces in AI answers.
Submitting to "AI search engines" directories: the crawlers found us through standard crawling plus IndexNow.

The checklist, condensed

Raw HTML contains your content (curl test) — client-rendered sites fix this first
llms.txt generated from the build, never hand-edited
robots.txt with explicit AI-crawler allowances (a decision, not an accident)
IndexNow for every new page
FAQ-shaped content that answers real questions in plain language
Measure: watch crawler UAs in your access logs, then watch for AI-domain referers

None of this is hard. All of it is the difference between being describable and being invisible when someone asks an assistant what to use.

Post #4 in the local-first series: #1 why 166 no-upload tools, #2 browser-side AI segmentation, #3 merging PDFs without a server. All tools: ToolVault.

Merging PDFs Without a Server: The Bytes Under a Structural Merge

tomcate — Mon, 21 Sep 2026 04:48:59 +0000

My last post covered running AI in the browser. This one is about the quieter member of the local-first family: PDF processing — merging, splitting, compressing — and what actually happens to the bytes when no server is involved.

The punchline first: a proper PDF merge does not "read" your documents the way a PDF viewer does. It rearranges serialized objects. Understanding that one sentence explains most of the behavior people find surprising in merge tools — and it shows why the whole operation fits comfortably in a browser tab.

A PDF is a database, not a document

Strip the format mystique away and a PDF file is a miniature object database: a header, a trail of objects (pages, fonts, images, streams), a cross-reference table pointing to each object byte offset, and a trailer. "Opening" a PDF means parsing that xref table, loading the page tree, and resolving references. Rendering is just one thing you can do after parsing.

Which means the three classic operations decompose like this:

Merge = copy the page objects of file B into file A's object space, remap their references, rebuild one xref table
Split = the mirror image: keep a subset of the page tree, carry over only the objects those pages reference
Compress (for scanned PDFs) = re-encode each page's embedded image stream (JPEG quality is your dial)

None of that requires rendering a single pixel. That is why our merge tool describes itself as "structural": pages come out byte-identical, text stays selectable, and a vector chart does not degrade, because it was never rasterized in the first place.

What pdf-lib gives you — and what it makes obvious

In the browser this is all pdf-lib, which is pure JavaScript with zero dependencies on native code or workers. The merge core is almost disappointingly small:

const out = await PDFDocument.create();
for (const file of files) {
  const src = await PDFDocument.load(await file.arrayBuffer());
  const pages = await out.copyPages(src, src.getPageIndices());
  pages.forEach(p => out.addPage(p));
}
const bytes = await out.save();

copyPages is where the object-remapping happens. Two things you learn from living with this API:

Page order is list order. There is no implicit sorting, no filename intelligence. If users expect page 10 to land after page 9, your UI has to enforce it — which is why reorder arrows exist and why "list order becomes page order" is the honest description.

What the tool does not preserve is as informative as what it does. Bookmarks that point to page positions shift. Form fields sharing a name across documents can collide — pdf-lib will not deduplicate them for you. Encrypted files need decryption before load or they throw. None of these are bugs in the library; they are the format showing its database nature.

Compression is where honesty matters

The interesting decision in a browser PDF compressor is what to do when compression makes the file bigger.

Scanned PDFs — one big image per page — compress beautifully: re-encode each page image as JPEG at quality 50-65 and 60-90% of the size evaporates, because the 300 DPI scan carries resolution nobody consumes. Vector PDFs generated by Word or LaTeX are already tiny; re-rendering them as images inflates them.

So the honest compressor has three behaviors: compress scans aggressively, and when the output grows, say so (+12% on the button, not a silent download) and point users toward splitting instead. Tools that always claim victory are lying to somebody.

The browser implementation detail that surprised me: canvas-mediated JPEG re-encoding of page images is where the quality dial actually lives, and quality-to-size is emphatically not linear — the useful cliff for scanned documents sits between 50 and 65, where halving the quality costs you single-digit percent of visual fidelity.

The privacy argument, restated for files people actually have

For portrait photos, local processing is a nice property. For PDFs it is closer to the whole point, because the documents that trigger PDF operations are disproportionately the sensitive ones — contracts under negotiation, visa applications, bank statements. The flow "I need to merge two files" should not have a mandatory step of "upload my signed contract to a random web service."

The verification is the same as always: DevTools, Network panel, watch zero requests leave while you work. Our complete guide to the PDF toolkit goes deeper on when to merge vs split vs compress — with the same no-upload guarantee.

What is hard in the browser (an honest list)

Encrypted PDFs: pdf-lib supports loading some variants but not decrypting all of them; the correct UX is a clear error, not a partial file
OCR: converting scanned pages back to selectable text needs a heavy model; we shipped without it rather than fake it
Very large merges: a few hundred pages works; ten thousand stresses mobile Safari memory — structural merging is cheap, but the file still has to exist in RAM once

None of these are server-shaped problems pretending to be local. They are the honest boundaries of the approach, and knowing them is the difference between a local tool and a local toy.

This is post #3 in the local-first series: #1 why we built 166 no-upload tools, #2 browser-side AI segmentation. All 166 tools live at ToolVault.

Running AI Portrait Segmentation Entirely in the Browser — Bugs Included

tomcate — Sun, 20 Sep 2026 04:06:40 +0000

My first post here mentioned that our ID-photo tools run portrait segmentation locally — a passport photo never leaves your machine. A few readers asked how that actually works, so here is the deep dive, including the three bugs that nearly shipped to production.

The stack is deliberately boring

MediaPipe Selfie Segmentation, compiled to WASM, loading a 244KB tflite model from our own origin (no CDN, no Google API key, works offline once the PWA is installed). The pipeline:

File → createImageBitmap → <canvas> → segmenter.segment(canvas)
     → categoryMask (Uint8Array) → custom mask pass → composite → download

Everything after the file picker is client-side JavaScript. The "server" is nginx serving static files — there is nothing to send data to.

Bug #1: The mask was inverted, and the specs were no help

The segmentation call returns a categoryMask. Intuition says: non-zero pixels = person, zero = background. MediaPipe's convention is the opposite: 0 is the person.

We shipped the intuitive version. The result: users uploaded a portrait, picked "blue background", and got a photo where the person was painted solid blue and the background stayed untouched. The bug report was a screenshot of a smurf.

The fix is one line — invert the predicate — but the lesson stuck: when a library hands you an opaque byte array, write a 10-line visualization dump before building anything on top of it. We now render the raw mask as grayscale before every mask-processing change.

Bug #2: The 1-pixel white halo that took three rounds to kill

After recoloring, every hair edge showed a white fringe. Classic cause: the mask boundary is a hard 0/1 cut, but anti-aliased pixels at the boundary are half-person, half-background.

Round 1: dilate the person region by 1px. Better, halo narrower.
Round 2: 2px. Better still, but now ears looked slightly "eaten".
Round 3 — the actual fix was two changes:

Dilate the background side by 3px (paint background color slightly into the person), and
Remove the feathering entirely.

That second one is counter-intuitive. We had added edge feathering (alpha-blend the mask boundary) for softness — but feathering blends the new background color at reduced opacity, which is exactly what a translucent white-ish fringe is. Hard edges beat pretty edges here; hair detail survives better with a slightly aggressive dilate than with a soft, diluted boundary.

Bug #3: Safari and `createImageBitmap`

createImageBitmap(file) — the clean, efficient entry point — is unavailable in older Safari. The fallback is an <img> element with objectURL, awaited through img.decode():

const source = typeof createImageBitmap === 'function'
  ? await createImageBitmap(file)
  : await new Promise((res, rej) => {
      const img = new Image();
      img.onload = () => res(img);
      img.onerror = rej;
      img.src = URL.createObjectURL(file);
    });

Both paths end in the same canvas.drawImage, so downstream code never knows the difference. Feature-detect at the edge, normalize immediately.

What "local AI" buys you in practice

A passport photo with face, ID number, and biometric pattern never touches a server — not because of a policy, but because there is no upload code path at all. F12 → Network proves it live.
It works on a plane, behind the great firewall, and on a locked-down corp machine.
Model inference at ~100-300ms per photo on a mid-range phone. Users cannot tell it is not a server call.
Our "server" cost for this feature is 244KB of static bandwidth.

None of this requires a special product. It requires rejecting the default architecture where "AI feature" means "API call".

Try it

The ID-photo background changer is live (pick any color, standard sizes for Chinese/US/visa formats, print layouts):
ToolVault ID Photo

If you are building client-side ML: what's the weirdest silent failure you have debugged in a byte array? That mask inversion took us a user screenshot to find — I am curious what yours took.

More local-first tools: 166 tools, zero uploads. First post in this series: why we built it.

I Built 166 Developer Tools That Never Send Your Files to a Server

tomcate — Tue, 15 Sep 2026 06:41:06 +0000

Every time I needed to convert a HEIC photo, merge two PDFs, or resize an ID photo, the search results led to the same kind of site: "Upload your file here." A passport photo. A contract PDF. A spreadsheet with real data. All shipped off to some unknown server, processed, and hopefully deleted.

I wanted the opposite. So I built ToolVault — 166 developer and productivity tools where every computation runs in your browser and zero bytes of your input leave your machine.

What's in the box

Data conversion: JSON ↔ YAML ↔ XML ↔ CSV ↔ Excel, Excel → Word, Markdown → Docx
Image tools: HEIC/WebP/AVIF/SVG conversions, batch resize, images → PDF
PDF suite: merge, split, PDF → JPG, compress — all via pdf-lib, all client-side
ID photo tools: background replacement, standard sizes, print layouts. Portrait segmentation runs a 244KB MediaPipe tflite model in the browser — your photo never touches a server
Dev staples: JWT decoder, regex tester, Cron parser, CIDR calculator, hashing, AES/RSA encryption, diff, code formatters
Workflows: chain multiple tools into a pipeline, so you stop copy-pasting between tabs

The architecture is the privacy policy

Most "online tools" are thin clients over a backend conversion service. ToolVault is statically exported Next.js — 998 pre-rendered pages served as plain files. There is no backend. No database. Nothing to leak, nothing to breach, nothing to subpoena.

That sounds like a slogan, so here's how to verify it yourself: open any tool, hit F12, watch the Network panel while you use it. Upload bytes: 0. Not "we promise" — observable.

A few implementation notes that made this work at scale:

Library choices matter. Everything runs on battle-tested client-side libraries: pdf-lib, pdf.js, SheetJS, heic2any, jszip, marked. The hard part is composing them (e.g., Safari's createImageBitmap gaps, which needed an <img> decode fallback).
Offline is a feature, not a gimmick. It's an installable PWA. Install it once, disconnect your network, and all 166 tools keep working. "Works on a plane" is the honest privacy demo.
Segmentation without the cloud. The ID-photo background remover runs MediaPipe Selfie Segmentation locally via WASM. The trickiest bug wasn't the model — it was realizing the category mask semantics were inverted from what I assumed (0 = person, not background), and a 3px background dilation needed to kill halo artifacts.

Why this matters more than it seems

When a tool uploads your file, you're making a trust decision — about their security, their employees, their acquisition by someone worse. When the computation is local, there is no trust decision. The browser sandbox is the policy.

This is also where tool sites are heading: WebAssembly and mature client-side libraries have removed most reasons for a conversion backend to exist. The remaining reason is usually ad-driven engagement ("watch our progress bar while we upload").

Try it

👉 https://www.wcytcn.com — no signup, no login, no upload. Your bookmarks are the account system.

If you have a tool you use weekly that doesn't have a "never uploads" version, tell me in the comments — that's my backlog.

DEV Community: tomcate

I Published 24 Articles in 5 Days. Here's What Actually Moved — and What Took 3 Days to Show Up.

The shape of the sprint

What moved immediately

The quota war nobody warns you about

What took three days to show up

What quietly broke

The scoreboard

What I'd do differently

Try it

A "Review-Safe" Cookie Banner Blinded 98% of My Analytics for 36 Hours (Postmortem)

The setup

The silence

Why it took 36 hours to notice

The fix: opt-out, and why it's still compliant

The counterfactual that made us take it seriously

Four guardrails we now run

Try it

I Turned a Real Security Incident Into a Benchmark. 6 Models Audited the Code That Lied.

The benchmark: one real file, two variants

The models

Result 1: the ceiling is four out of seven

Result 2: mentioning is not finding

Result 3: my hypothesis was wrong — the comments helped

What I would measure next

Try it

My Site Has No Backend — Except One Route. Auditing It Found 4 Real Holes.

Hole #1: the redirect that walked past the bouncer

Hole #2: two DNS lookups means you checked a different host than you connected to

Hole #3 and #4: the client-side bugs an audit caught for free

The quiet ones: rate-limit trust and control headers

The checklist, compressed

Making a Tool Site Legible to AI Assistants: GEO in Practice

First, the uncomfortable physics: AI crawlers do not run JavaScript

llms.txt: useful convention, fatal if hand-maintained

robots.txt: decide, explicitly, who you let in

The reward loop is real, and measurable

What did not matter (for us, so far)

The checklist, condensed

Merging PDFs Without a Server: The Bytes Under a Structural Merge

A PDF is a database, not a document

What pdf-lib gives you — and what it makes obvious

Compression is where honesty matters

The privacy argument, restated for files people actually have

What is hard in the browser (an honest list)

Running AI Portrait Segmentation Entirely in the Browser — Bugs Included

The stack is deliberately boring

Bug #1: The mask was inverted, and the specs were no help

Bug #2: The 1-pixel white halo that took three rounds to kill

Bug #3: Safari and createImageBitmap

What "local AI" buys you in practice

Try it

I Built 166 Developer Tools That Never Send Your Files to a Server

What's in the box

The architecture is the privacy policy

Why this matters more than it seems

Try it

Bug #3: Safari and `createImageBitmap`