DEV Community: Lakhyajit Changmai

Local file processing needs a precise boundary

Lakhyajit Changmai — Mon, 02 Nov 2026 07:52:46 +0000

`“The file never leaves your browser” sounds simple, but it can describe only part of the data flow. A web app still downloads its HTML, JavaScript, and other assets. The useful question is what happens to the bytes a person selects.

For ZANCTA’s supported PDF and image workflows, processing happens in the current browser tab. That means the page should explain this boundary plainly: files are processed locally while the website itself still loads normally.

This distinction also keeps the claim honest. Local processing does not mean every operation is available offline, and it does not remove the need to explain browser permissions, file limits, or the behavior of each tool.

When you build a file utility, make the data path visible: which inputs are handled locally, which operations have limits, and what is transmitted to the service. Clear language helps users decide whether a tool fits their document and their threat model.`

crossOriginIsolated is a tradeoff, not a checkbox - why my in-browser ML model runs single-threaded

Lakhyajit Changmai — Fri, 30 Oct 2026 15:05:38 +0000

crossOriginIsolated is a tradeoff, not a checkbox — why my in-browser ML model runs single-threaded

If you run an ONNX model in the browser with onnxruntime-web, the multithreaded WASM build wants SharedArrayBuffer. And SharedArrayBuffer is only available when the page is cross-origin isolated, which means you've shipped both a COOP and a COEP header.

The tempting advice is "just enable cross-origin isolation." I want to show why we deliberately did not, in a real production app, and what the honest tradeoff looks like.

What we actually do

Our background-removal tool self-hosts a small model (u2netp) and runs it through onnxruntime-web's wasm bundle. The relevant part of our engine, verbatim:

const ort = (await import("onnxruntime-web/wasm")) as unknown as OrtModule;
if (!ortConfigured) {
  ort.env.wasm.wasmPaths = BG_WASM_BASE;
  // This site is not cross-origin isolated, so SharedArrayBuffer threading is
  // unavailable; pin to a single thread to avoid a broken threaded init.
  if (typeof globalThis.crossOriginIsolated === "undefined" || !globalThis.crossOriginIsolated) {
    ort.env.wasm.numThreads = 1;
  }
  ort.env.wasm.proxy = false;
  ortConfigured = true;
}

We detect isolation with globalThis.crossOriginIsolated and, when it's false, pin numThreads = 1 instead of letting a threaded init half-break. We also show a "compatibility mode" message rather than an error. The model just runs single-threaded.

Why not just turn on COOP/COEP?

Because COEP changes the rules for every cross-origin subresource on the page. With Cross-Origin-Embedder-Policy: require-corp, anything you load from another origin has to opt in with a Cross-Origin-Resource-Policy header (or CORS). If it doesn't, the browser blocks it — silently.

Our own decision log is blunt about this. The note next to the threading section reads:

Threading requires Cross-Origin-Isolated for wasm_threads. If not isolated, gracefully fall back to single-thread WASM (feature detect, show "compatibility mode"). Do not require COOP/COEP headers in MVP — they break OAuth/ads.

require-corp would have broken our OAuth sign-in popup and the third-party scripts we legitimately load, all to win threading on one optional, occasionally-used tool. For a privacy-first tool where the headline is "your file never leaves the tab," making the whole page's resource loading more fragile to buy some inference speed on the heaviest feature was not a good trade. The small model + single-thread fallback was the honest engineering call.

I want to be equally honest about what I didn't do: I have no measured, per-device speed numbers for single- vs multi-thread on our exact model. The decision was structural (does isolation break the things I need?), not a benchmark win I can quote.

The third option I didn't know about

This came up in a thread with @szp2005, who runs a heavier matting model in the browser. When I described our not-isolated, single-threaded setup, they pointed out that we weren't limited to the binary "isolation vs. broken analytics" I'd assumed. Their words:

We do isolate, using COEP: credentialless instead of require-corp. Safari ignores it and stays single-threaded.

That reframed the whole choice for me. credentialless lets cross-origin subresources load without credentials and without each resource sending a CORP header — so you get the isolation (and the threaded WASM) without forcing every third-party embed to opt in first. The exact embed-blocking that made require-corp unusable for us largely stops applying.

And the Safari caveat is the part that actually matters. If a browser ignores credentialless, then cross-origin isolation is a progressive enhancement, not a guarantee. You cannot design the happy path assuming isolation is on, because there is always an engine where it silently isn't. Which is exactly why our numThreads = 1 fallback and their "timeout retry had to start a new Worker" both have to exist regardless of which COEP mode you ship.

Takeaways

Treat crossOriginIsolated as a capability you feature-detect, never a precondition you assume. Ship the single-threaded path first.
require-corp is a page-wide contract with every third-party you load; that's a big blast radius for a speed win on one feature.
COEP: credentialless is worth testing specifically because its failure mode (blocking non-CORP embeds) is the one that usually disqualifies COEP — but plan for the engines that ignore it.
The right question isn't "how do I get multithreaded WASM," it's "what does turning on isolation break, and is the thing I gain worth it."

If you've wrestled with credentialless vs require-corp in a real app, I'd genuinely like to hear where it held and where it didn't.

Disclosure: drafted with AI assistance from my own source code and the linked conversation; every code excerpt and quoted claim was checked against the actual repository before publishing. I wrote and verified the content.

Five rich-text editors, five ways to inject text, and the layer that actually matters

Lakhyajit Changmai — Tue, 27 Oct 2026 17:36:11 +0000

The DOM is not the source of truth. That sounds obvious, and it is the thing that breaks almost every browser agent that edits text on a page. The field fills, the save endpoint answers 200, and the value stored is empty. I hit this five times in one day on five different editors, and the fix was always the same idea: find the layer the submit handler reads from, and write to that one.

Three layers, only one of which is authoritative

Most text inputs on the modern web are not the node you can see. They are a stack:

the DOM - what is rendered
the editor document - ProseMirror state, Quill's internal model, Draft.js ContentState
the application store - the React or Redux state that builds the request body

element.value = ..., innerText = ... and document.execCommand(...) touch layer 1, or reach layer 2 by accident. The submit handler serialises layer 3. When nothing propagates upward, you get a clean, successful no-op.

What follows is what worked on each editor. All of it was found the slow way.

1. ProseMirror: `beforeinput`, not `execCommand`

ProseMirror listens for the beforeinput event and mutates its document in response to it. It does not read what you write into the DOM.

const el = document.querySelector('.ProseMirror');
el.focus();
const ev = new InputEvent('beforeinput', {
  inputType: 'insertText',
  data: text,
  bubbles: true,
  cancelable: true,
  composed: true,
});
el.dispatchEvent(ev);

document.execCommand('insertText') and driver-level typing both produced the same result here: the text appeared in the field, Save returned success, and the stored document was one empty paragraph.

2. Tiptap: a real paste payload

Tiptap is ProseMirror underneath, but its paste handler is the part you can reach. Dispatch a synthetic clipboard event carrying a real DataTransfer:

const dt = new DataTransfer();
dt.setData('text/plain', text);
const consumed = !editorEl.dispatchEvent(
  new ClipboardEvent('paste', { clipboardData: dt, bubbles: true, cancelable: true })
);

Check consumed. dispatchEvent returns false only when a handler called preventDefault(), so that boolean is your proof the editor took the payload rather than the browser shrugging at it.

3. Quill: `execCommand` works, and it multiplies newlines

Quill ignored the synthetic paste entirely but accepted this:

editorEl.focus();
document.execCommand('insertText', false, text);

One quirk cost me a visible edit: Quill expands paragraph breaks, so two newlines in came back as four blank lines out. Author with single newlines and re-read the result before publishing.

4. Draft.js: only trusted input, and `innerText` lies

Draft.js (X's composer) keeps its text in its own render nodes:

const stateText = composer.querySelector('span[data-text="true"]').textContent;

Use that as the oracle, not innerText. After an execCommand write, Draft.js leaves a sibling text node that React never reconciles, so innerText double-counts and the character counter reports a number that is not true of the state. I published a truncated post believing that counter.

Synthetically, nothing works on Draft.js: beforeinput is ignored, and a synthetic paste is consumed but inserts nothing. Only a real browser-level keystroke updates its state.

5. The case that broke my own rule: editor state was also the wrong layer

I was ready to end this article at write to the editor state. Then a Tiptap composer that mirrors itself into a Redux store refused to publish.

I set content through the editor API and verified everything I thought mattered: the document held 1,813 characters, the update event fired, the DOM rendered the text. The request body the app sent was:

{ "caption": "", "postTitle": "Automated text entry is a state problem, not a DOM problem" }

Empty caption. The same text delivered through the clipboard paste route in section 2 reached the store, and the identical payload published at 200.

Same visible result, one layer apart. Layer 2 was not authoritative either.

Verify against the payload, not the page

Hook the network before diagnosing anything:

window.__cap = [];
const open = XMLHttpRequest.prototype.open;
const send = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.open = function (m, u) {
  this.__u = u; this.__m = m;
  return open.apply(this, arguments);
};
XMLHttpRequest.prototype.send = function (b) {
  window.__cap.push({ url: this.__u, method: this.__m, body: b });
  return send.apply(this, arguments);
};

Then assert exactly one of three things: the outgoing request body contains your text; the framework document contains it (editor.state.doc.textBetween(...), editor.getHTML()); or a cold reload of the page shows it. The reload is the only proof that reaches layer 3.

Two smaller findings that cost real time

A disabled submit button is usually a validation message that moved somewhere else. In the Peerlist composer, the server's 400 string was bound to the button's disabled prop, so an over-length caption presented as a permanently dead button plus a generic error. The actual limit - 480 characters - only appeared as helper text once the content was already short enough. No counter, no warning while you are over it.

On React-controlled inputs, input.value = x does nothing, because React reads through its own descriptor and overwrites you on the next render:

const set = Object.getOwnPropertyDescriptor(HTMLTextAreaElement.prototype, 'value').set;
set.call(ta, text);
ta.dispatchEvent(new Event('input', { bubbles: true }));
ta.dispatchEvent(new Event('change', { bubbles: true }));

The part that is not a trick

Every editor in this list is behaving correctly. The bug is the assumption that what you can see is what gets saved. That assumption survives for a long time, because the failure is quiet: the UI looks right the whole way through, and the only artefacts that tell the truth are the request the app sends and the page you load ten minutes later.

I build ZANCTA, a set of local-first PDF and image tools that run entirely in the browser tab, so the general shape of this problem is familiar to me: if the state you are reading is a copy of the state that matters, you will be confidently wrong.

I grepped my own app for file-upload paths. There is exactly one, and it is the contact form

Lakhyajit Changmai — Tue, 27 Oct 2026 13:00:50 +0000

The claim, stated precisely

ZANCTA is a browser-based PDF and image tool suite: 17 tools, all defined in one registry file. The claim on the landing page is not "we do not store your files". It is stronger and much more checkable: no tool ever sends file bytes to a server.

That is falsifiable with a text search, and every app with a privacy claim on its landing page should run the search.

Step 1: enumerate every way bytes could leave

Upload primitives in a browser app are few and boring:

new FormData() sent via fetch or XMLHttpRequest
a File or Blob passed as a fetch body
navigator.sendBeacon
base64-encoding a file into a JSON field (the sneaky one)
an input type=file whose contents get read and posted

Grepping the app surface for the first three produced exactly one hit:

components/contact/contact-form.tsx:31 - const data = new FormData(form)

Text fields only: name, email, message. No file input in that form.

Then the sneaky one. FileReader and arrayBuffer() calls are everywhere, because every tool has to read its own files. The question is what happens after the read. The answer, here: pdf-lib, pdfjs-dist, browser-image-compression, libheif-js, tesseract.js, onnxruntime-web, qrcode, spark-md5, and a handful of Web Workers. All client libraries. That is the entire processing surface.

Step 2: audit the server side

35 route files under app/api/**/route.ts. Sorted by what they touch: auth and session, account deletion, entitlements, payments, admin SEO integrations, analytics, contact, health, OCR language delivery, IndexNow. None of them accept a file. Zero handlers call req.formData() or read an arrayBuffer.

One group looks alarming if you only read the names. Premium adds six OCR languages plus scanned-PDF OCR, and Tesseract needs .traineddata files to do that:

app/api/ocr/lang-token/route.ts
app/api/ocr/lang/[...file]/route.ts
app/api/ocr/status/route.ts

The handler is GET only. The server issues a token, then serves the language pack down to the browser. Your document never goes up. The direction of the arrow is the whole claim.

Step 3: the route that does receive something about your files

One analytics endpoint records that a tool run completed. It is the only server route that learns anything about your processing, and its guardrails are worth stealing:

It accepts one field: a tool slug, validated against an allowlist built from the tool registry.
MAX_BODY_BYTES is 512, checked against both the Content-Length header and the actual parsed payload. The comment in the code says why: reject anything larger rather than parsing a payload that could carry file data.
Cross-origin requests are rejected before parsing.
Anonymous calls are stored with userId null and no IP or user-agent, so the row cannot identify a person.
Extra body fields are read and discarded, never stored.
Analytics failures are swallowed so a telemetry bug can never surface as a tool failure.

That last group is the interesting bit: the size cap is not hygiene, it is the privacy guarantee. A claim enforced by "we promise not to send more" is a claim enforced by nothing.

Step 4: what running locally actually costs

Nothing is free. Local processing buys privacy by moving weight onto the client:

public/models/u2netp.onnx is 4,574,861 bytes - the background-removal model, fetched before the first removal works.
public/ocr/ holds 14 WASM and worker assets.

So the honest phrasing is: your file bytes are not uploaded. Not: the app needs no network. It loads scripts, models, and consent-gated analytics. Anyone who writes "100% offline" and "no tracking whatsoever" on a landing page is writing copy, not engineering.

Step 5: the audit caught two real false statements

Both were in my own documentation rather than the code:

README.md and CHANGELOG.md say "Eleven local PDF and image tools" and then list eleven. The registry has seventeen. The docs were six tools stale.
README.md and the llms.txt route both say background removal is "PLANNED - deferred: no model and no cloud fallback". A 4.5 MB ONNX model ships in public/models/ and the component is fully implemented. Both statements are false today.

Neither was malicious. Both are exactly how privacy claims rot: someone writes a summary at the moment it happens to be true, the code moves, nobody re-reads the summary.

There is also a live contradiction I have not resolved. This branch adds background-remover to a non-indexable list, so a tool that works is deliberately kept out of the sitemap. That is a defensible discovery decision, but it means "what the site advertises" and "what the app does" now disagree on purpose - and I have to pick one before the next public description goes out.

What the audit lets me publish

Checkable: 17 tools, all processing in the tab; one FormData in the app and it belongs to the contact form; every API route accounted for by name; OCR weights served down instead of documents collected up; a 512-byte cap on the only telemetry route that touches processing.

Not checkable, and competitors do it constantly: user counts, "trusted by", accuracy percentages, "unhackable", "completely anonymous". None of those have a grep.

If your landing page makes a privacy claim, run the search this afternoon. The distance between what the page says and what the code does is where trust gets spent.

What browser-local file tools actually cost you

Lakhyajit Changmai — Fri, 16 Oct 2026 06:28:29 +0000

I build ZANCTA - 17 PDF and image tools that run entirely in the browser. No uploads, no server-side processing. I chose that constraint on purpose, and I want to write down what it actually costs, because the pitch version of "privacy-first" hides all of it.

1. Model size is a product decision, not an engineering one

The background-removal model is an ONNX network running in WebAssembly. The equivalent server-side pipeline could ship a model an order of magnitude larger, and it would be visibly better at hair edges.

I do not get to make that trade on quality alone. A user on a metered connection will close the tab before a 40 MB download finishes. So the download budget gets decided first - how long will someone realistically wait - and the quality ceiling falls out of it. Same on OCR: the model that handles a scanned document well still has to be small enough that a user will actually wait for the download.

If you are shipping anything with a model to the client, your first constraint is not accuracy. It is patience.

2. Closing the tab is a Tuesday, not an edge case

On a cloud PDF tool, if the user closes the tab mid-merge, the server keeps working and the file shows up in an email a few minutes later. The failure is invisible.

On a browser-local tool, closing the tab kills the process. There is no fallback tier. So work that is invisible for a server-side competitor becomes mandatory here: a resumable local queue, real progress reporting, and being honest about what happens when a job is interrupted. Nobody sees any of it when the tool is working fine. You pay in development time and get no visible feature.

3. Memory is the ceiling on input size

Everything happens inside one tab's heap. A large PDF or a high-resolution image is not a slow operation, it is frequently an impossible one. On a normal-size photo, in-browser background removal takes roughly ten seconds on desktop Chrome, which is tolerable. What I am most nervous about is iOS Safari tab-memory limits on large inputs. I have not benchmarked specifically on low-end Android yet, and I would rather measure than guess at it.

4. What the numbers actually look like

Publishing these because the useful version of a build log is the one with figures in it, and mine are small.

Last 30 days:

83 sessions, 533 page views
17 active users in GA4, 1 registered account
Search Console: 45 impressions, 3 clicks, average position 13.3
Revenue: 0 INR. Active subscriptions: 0
Checkouts started: 1. Completed: 0

Per tool, from server and client events:

Tool	Views	Started	Completed
background-remover	5	2	2
image-compress	3	2	2
ocr	3	1	1
pdf-text-extractor	2	1	1
pdf-merge	2	0	0
images-to-pdf	2	0	0
checksum	1	0	0

Two things that table says, and only one of them is bad news.

The product is not the bottleneck. Every tool that got started got completed. One hundred percent across the board. Whatever is wrong is upstream of the tool.

The bottleneck is that nobody arrives. 45 Search Console impressions in a month, for a site in a category that is searched constantly. And look at what those impressions are for - the top queries are sha check, sha256 verify, and zancot, which is people misspelling my own brand. I am not ranking for a single head term in the category I built for.

That second one reframed the project. I put the effort into the tools and effectively none into the two things that would have made them findable.

5. What I got wrong about distribution

I relaunched on Product Hunt in October with better positioning than the first attempt: one flagship capability (in-browser OCR) instead of a list of seventeen tools, a clear hook, the maker comment written in advance.

It got one upvote. Mine.

Nothing about the product changed between the two launches. The only variable was an audience that was not there. I had treated the launch as an event and assumed distribution follows from shipping something good. It does not. Distribution is a separate product, and I had built neither a launch audience nor a search presence. I had built a nicer landing page.

The demand that converts for a file tool is search-shaped, not browse-shaped. Someone holding a tax document and a converter that just demanded an upload has the problem right now, and they are typing it into a search engine. Nobody browsing a launch directory has that problem this morning.

Where it goes from here

The completion rates say the engineering bet was right. The impression counts say everything around it was wrong. Effort is moving off tool count and onto the small number of pages that answer a specific blocked question completely, measured by completed files rather than visits.

If you have shipped a technically sound product into approximately zero demand, I would genuinely like to know what you changed first.