DEV Community: Tasleem Akhtar (#Ch)

What "Runs Entirely in Your Browser" Actually Means: A Developer's Guide to Client-Side File Tools

Tasleem Akhtar (#Ch) — Wed, 16 Sep 2026 08:45:23 +0000

Most free online tool sites print some version of the same promise in their footer: "your files never leave your device." Some sites mean it. Some mean "we process it, trust us." The good news for developers: this is one of the few privacy claims you can personally audit in about a minute with DevTools, no vendor questionnaires required.

In this post I'll break down what the claim actually requires technically, walk through three categories of browser-side tools with real worked examples (including a compression test I ran specifically for this article), and give you a 60-second checklist for verifying any tool's claim yourself.

The spectrum: client-side, hybrid, server-side

Almost every "free online tool" falls into one of three buckets:

True client-side. Your file is read by the browser's File API, processed by JavaScript or WebAssembly running in the page, and handed back to you as a Blob download. The network is never touched during processing. Privacy here is a technical property, not a promise — you can watch it not happen.

Hybrid. Part of the job happens locally, part touches a server. A URL expander, for instance, must fetch the remote URL by definition. A downloader that pulls a video for you is making network requests to someone else's infrastructure. These tools can be perfectly legitimate, but "your files never leave your device" would be false advertising for them.

Server-side. The file is uploaded, processed on someone's server, and sent back. This is how many popular PDF utilities have traditionally worked. It's not automatically malicious — but it means your document transits and (transiently) exists on hardware you don't control.

The interesting category is the first one, because the mechanism is genuinely elegant. Let's look at three real examples.

Example 1: image compression with the HTML canvas

The humble <canvas> element can do something people rarely think about: decode an image, draw it, and re-export it at a chosen quality setting. That's the entire mechanism behind browser-based image compression — no server, no upload, just re-encoding pixels your browser already holds in memory.

I verified this against the copy on Toolfyra's free image compressor, whose FAQ states it plainly: "Compression uses the HTML canvas on your device — files never leave your browser." The tool accepts JPG, PNG and WebP input, and offers two modes:

a quality slider, where you pick a quality level and see what comes out, and
a target size mode, where you specify something like "under 100 KB" and the tool binary-searches the quality level until the output fits while keeping quality as high as possible. (Their FAQ describes exactly this: "It binary-searches the quality level to get under your KB limit with the highest possible quality.")

Why does quality matter so much? Because JPEG size is wildly sensitive to it. Here's a real test I ran for this article — Python's Pillow library, a noisy 2048×1536 test frame (noise compresses about as stubbornly as a detailed photograph):

Encoder setting	Output size	vs. q90
PNG (lossless, same frame)	9,229 KB	—
JPEG quality 90	2,528 KB	100%
JPEG quality 70	1,613 KB	64%
JPEG quality 50	1,174 KB	46%
JPEG quality 30	792 KB	31%

Dropping from q90 to q50 cut the file to less than half the size on this frame. Whether the visual loss is acceptable is a judgment only you can make for a given image — that's precisely why a slider plus a live preview beats a one-shot "compress" button.

The binary search for a target size is also nice little math. If quality runs from 0 to 100, log₂(100) ≈ 7 compression attempts are enough to pin the quality within ±1 of the largest value that fits your KB budget. When a job portal demands a photo under 100 KB, that's the difference between five manual "try and check" rounds and one click.

Example 2: merging PDFs with an in-browser library

For years, "merge PDF online" meant uploading your documents — sometimes a job application, sometimes a contract — to a stranger's server. The modern alternative: a library like pdf-lib running inside the page, which assembles PDFs locally.

Toolfyra's merge PDF page says it uses "PDF-LIB in your browser: files are never uploaded, which also makes it faster and private." The workflow is deliberately boring, which is what you want in a utility:

Add two or more PDFs (drag-and-drop or file picker) — they stay on the device.
Check the order. The page gives you ↑/↓ buttons per file rather than drag-to-reorder, which is honestly more reliable on a phone.
Merge. Files concatenate top-to-bottom in list order.
Download the combined PDF.

A concrete example: a job application needs cover letter, CV, and two certificate scans as one document. Add them in that order, merge, done — the combined file is assembled in browser memory from bytes that were never sent anywhere.

The honest limitations, straight from the same page's FAQ: there's no hard file-count limit, but "very large combined files may be slower on older phones." And merging is concatenation, not compression — if you need the output smaller, that's a different operation (and a different quality trade-off, as the table above shows).

Example 3: JSON formatting with the browser's own JSON engine

This one is almost mundane: JSON.parse() and JSON.stringify() are built into every browser. A JSON formatter is UI wrapped around them — but the UI is where the value is.

Toolfyra's JSON formatter and validator runs entirely with the browser's own JSON engine ("Is my API data sent to a server? No — parsing happens with your browser's own JSON engine, locally," per its FAQ). It beautifies at 2 spaces, 4 spaces, or tabs, minifies for production payloads, and — the part I actually care about — pinpoints syntax errors with a line and column.

Worked example. You pull a config from a service and it fails to load. The cause is a trailing comma:

{
  "service": "billing",
  "retries": 3,
  "timeout_ms": 2500,
}

A raw JSON.parse in your console gives you an error that's technically accurate and practically unhelpful. A good validator tells you where: line 5, the trailing comma after the last property. The same tool's FAQ lists the usual suspects it was built for — single quotes instead of double, trailing commas, unquoted keys, and Python-style True/False/None where JSON wants true/false/null. If you've ever pasted Python dict output into a JS context, you've hit all four.

The page is also upfront about scale limits: multi-megabyte payloads are fine, but beyond roughly 10 MB the browser may slow down. That's a fair and honest caveat — you're asking a UI thread to pretty-print a string.

The same pattern (browser-native engines, zero upload) covers a lot of ground beyond these three — Toolfyra's toolbox alone includes an OCR text extractor that recognizes text from images and PDFs on-device. The point isn't any one tool; it's that the pattern has matured.

The 60-second audit: verify any "client-side" claim yourself

Here's the checklist I use before pasting anything remotely sensitive into a web tool:

Open DevTools → Network tab before touching the tool. Clear the log.
Do the operation. Watch for POST requests whose body size grows with your file, upload progress bars, or requests to endpoints you didn't trigger. A genuinely local tool shows a quiet Network tab during processing.
The gold standard: go offline. After the page has loaded, switch DevTools to Offline throttling (or actually disconnect), then run the operation. If it still works, the computation was local. A server-side tool physically cannot pass this test.
View-source and search for fetch(, XMLHttpRequest, WebSocket. Endpoints that exist for analytics are normal; endpoints receiving your file content are not.
Read the privacy page — for the analytics, not the file handling. Processing locality and site analytics are two separate claims. Toolfyra, for example, runs Google Analytics behind a Consent Mode v2 banner that stays denied until you accept, while file processing happens locally. Those facts coexist; a page claiming both "zero analytics" and "free tools" deserves extra skepticism.

Honest caveats about the client-side model

To keep this article honest, the trade-offs:

Client-side ≠ anonymous. As above, analytics and file processing are separate layers. Judge them separately.
First loads are heavier. In-browser engines — OCR especially — can run to multiple megabytes on first download. After caching, it's fine — but it's a real cost.
Your hardware is the ceiling. Old phones are the constraint for big files, not some remote datacenter. That's the price of the files staying yours.
Some jobs genuinely need a server. Anything that must reach out to a third-party service on your behalf is hybrid by nature. The privacy claim to look for is precision: which part runs where.
"It didn't make network calls" is not a security audit. It's a point-in-time observation. For anything truly sensitive, the offline test plus a view-source scan is due diligence, not a guarantee.

Takeaways

"Runs in your browser" is a checkable technical claim: quiet Network tab, works offline after load.
Canvas re-encoding gives you real image compression locally, including automatic target-size search.
pdf-lib in the page makes PDF assembly a local operation — order files, merge, download.
The browser's own JSON engine plus good error UI beats most desktop utilities for everyday API debugging.
Use the offline test. It takes ten seconds and it's the closest thing to proof the Web offers.

None of this requires trusting my description of any tool — including the ones I linked. That's the whole point: the verification mechanism is on your side of the screen.

Some drafts were prepared with AI assistance and reviewed by the site team.

SRT Subtitles: The Timing Rules Editors Learn the Hard Way

Tasleem Akhtar (#Ch) — Tue, 15 Sep 2026 05:00:00 +0000

SRT is the friendliest subtitle format ever designed — plain text, four fields per cue — and yet badly-timed SRTs are everywhere. The rules that fix 95% of them fit on one screen.

Rule 1: Lead with the cut, not the sentence. A cue should land on the shot change or the first audible syllable, whichever the eye meets first. Cues that float 300 ms late read as lag even when the audio sync is perfect.

Rule 2: Two lines, ~42 characters, 17–20 chars/second. Reading speed is the physics of subtitles. A cue that needs three lines or a 25 cps sprint loses viewers at the second line; split it instead. Minimum duration ~1 second, maximum ~6–7 — beyond that, re-readers appear.

Rule 3: Gap between cues. A 2-frame gap (≈80 ms) between consecutive cues lets the eye register the change; wall-to-wall cues blur into one endless subtitle.

Rule 4: Timestamps are HH:MM:SS,mmm --> HH:MM:SS,mmm — the comma before milliseconds is the hill SRT parsers die on. Export tools that write a dot instead break half the players on earth. (Yes, really.)

Rule 5: Verify on the worst player you ship to. Smart TVs and old Android players disagree about line breaks and positioning; test the minimum, not the average.

Our in-browser generator (https://toolfyra.com/video-subtitle-generator.html) builds spec-correct SRT with these rules baked in — timing, gaps, comma format — and exports locally, so transcript drafts never leave your machine. For the surrounding pipeline, the video tools index lives at https://toolfyra.com/sitemap.xml.

Keeping 4,200 Static Pages Fast on Free Tiers: The Build Discipline That Makes It Boring

Tasleem Akhtar (#Ch) — Mon, 14 Sep 2026 05:00:00 +0000

Our site serves 4,200+ pages — tools, guides, blogs — with no backend, on free-tier hosting. It stays fast because we treat speed as a build property, not a tuning exercise. Five disciplines do the work.

1. Static until proven dynamic. Every page is pre-rendered HTML. The only "server logic" is edge caching. When a tool needs compute, the compute ships as WASM to the browser — the server's job stays zero.

2. One generator, disk-truth sitemaps. The sitemap is generated from the files that actually exist, never from a database that can drift. Our integrity audit (https://toolfyra.com/sitemap.xml is the machine-readable truth) runs after every deploy and fails the release on any URL/content mismatch. Boring is the goal.

3. Cache headers as architecture. Immutable assets get year-long caching with hashed or versioned paths; HTML gets short TTLs so releases propagate in minutes. The 35 MB ffmpeg core is served once per visitor, then silence.

4. Budget the heavy things on-origin vs CDN. WASM engines live same-origin for privacy and CSP simplicity; the truly huge, rarely-changed binaries ride a CDN with long TTLs. The split is a deliberate line, reviewed when either side grows.

5. Measure from the reader's seat. Field-style checks — first byte, largest paint on a mid-tier phone profile — run in our release gate. Lab numbers lie politely; the phone profile doesn't.

The payoff is arithmetic: free tiers handle static traffic nearly forever, and our costs stay at zero because there is nothing to scale. The whole index, if you want to see what 4,200 static pages looks like: https://toolfyra.com/sitemap.xml.

25 Calculators Worth Bookmarking (Client-Side, No Signup, No Nonsense)

Tasleem Akhtar (#Ch) — Sun, 13 Sep 2026 05:00:00 +0000

Most calculator pages are ad-farm wrappers around one formula. The useful ones are fast, exact, and explain their math. Here are twenty-five we built to that bar, grouped by the question they answer — every one runs its math in your browser.

Money: mortgage (https://toolfyra.com/mortgage-calculator.html) · compound interest (https://toolfyra.com/compound-interest-calculator.html) · salary-after-tax (https://toolfyra.com/salary-after-tax-calculator.html) · tip (https://toolfyra.com/tip-calculator.html) · discount (https://toolfyra.com/discount-calculator.html) · ROI (https://toolfyra.com/roi-calculator.html)

Time & dates: age (https://toolfyra.com/age-calculator.html) · date difference (https://toolfyra.com/date-difference-calculator.html) · time zone (https://toolfyra.com/time-zone-converter.html) · overtime (https://toolfyra.com/overtime-calculator.html) · pomodoro planner (https://toolfyra.com/pomodoro-timer.html)

Health & body: BMI (https://toolfyra.com/bmi-calculator.html) · calorie needs (https://toolfyra.com/calorie-calculator.html) · body-fat (https://toolfyra.com/body-fat-calculator.html) · water intake (https://toolfyra.com/water-intake-calculator.html) · sleep cycles (https://toolfyra.com/sleep-calculator.html)

Home & DIY: paint (https://toolfyra.com/paint-calculator.html) · tile (https://toolfyra.com/tile-calculator.html) · concrete (https://toolfyra.com/concrete-calculator.html) · BTU (https://toolfyra.com/btu-calculator.html)

Math & conversion: scientific (https://toolfyra.com/scientific-calculator.html) · percentage (https://toolfyra.com/percentage-calculator.html) · fraction (https://toolfyra.com/fraction-calculator.html) · unit converter (https://toolfyra.com/unit-converter.html) · binary (https://toolfyra.com/binary-converter.html)

Why client-side matters even for math: no round-trip means instant answers, your inputs (salary, weight, debt) never become analytics rows, and the formulas work offline once cached. That last property is why these make good bookmarks rather than good ads.

The complete index of 4,200+ pages: https://toolfyra.com/sitemap.xml.

The On-Device PDF Stack: Nine Jobs You Never Need to Upload For

Tasleem Akhtar (#Ch) — Sat, 12 Sep 2026 05:00:00 +0000

PDF tools are the most-uploaded category on the internet — contracts, invoices, IDs — and the least deserving of upload. Every common PDF job now runs client-side. Here are the nine we ship, and the one-line reason each is safe to keep local.

Merge (https://toolfyra.com/pdf-merger.html) — concatenation is pure byte assembly; no server insight needed.
Split (https://toolfyra.com/pdf-splitter.html) — page ranges are structural; the content never needs eyes but yours.
Compress (https://toolfyra.com/pdf-compressor.html) — image downsampling and object-stream recompression run fine in a tab.
Word → PDF (https://toolfyra.com/word-to-pdf.html) — layout rendering is local compute, not a service.
PDF → Word/text (https://toolfyra.com/pdf-to-word.html) — extraction is parsing; your text stays home.
Rotate (https://toolfyra.com/rotate-pdf.html) — a metadata transform; uploading for it is absurd once you know.
Protect/unlock (https://toolfyra.com/protect-pdf.html) — passwords you type into a site are passwords the site sees; local encryption keeps them yours.
Sign (https://toolfyra.com/sign-pdf.html) — a signature on an uploaded contract is a signature stored on someone's disk.
OCR (https://toolfyra.com/ocr-pdf.html) — the heaviest job, and still local now: WASM OCR engines run the recognition on your CPU.

Why this list matters beyond privacy. Local means instant (no queue), unlimited (no daily caps), offline-capable, and jurisdiction-proof. A law office, a clinic, an accountant — anyone with document confidentiality — gets these properties for free once the engine is in the browser.

The honest limits. Server-side still wins for 500-page OCR batches and scanned-image cleanup at scale; choose it consciously for those, knowing what you're uploading. Everything else on the list has no reason left to leave your machine.

Browse the full document suite and the rest: https://toolfyra.com/sitemap.xml — and for any tool, the Network tab is the audit.

We Traced the Uploads: What "Free" File Converters Actually Do With Your Files

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 21:00:00 +0000

Last month we ran a simple experiment: converted the same 40 MB video through twelve popular "free online converter" sites while watching the network panel, the retention policies, and the fine print. The pattern was consistent enough to describe as a system.

What the trace showed. Every service uploaded the full file before converting — expected, since they're server-side. Less expected: six kept the file for "up to 24 hours" per their own policies, three routed uploads through a third-party storage bucket in a different jurisdiction, and two served the download link as a guessable URL with no expiry. One retained the filename in an analytics payload. None of this is illegal; all of it is invisible until you look.

The alternative architecture. The same conversions can run inside your browser tab now. FFmpeg compiled to WebAssembly demuxes, decodes, and re-encodes locally; the file never becomes network traffic. We built our media tools that way — compression (https://toolfyra.com/video-compressor.html), conversion (https://toolfyra.com/video-converter.html), trimming (https://toolfyra.com/video-trimmer.html), merging (https://toolfyra.com/video-merger.html), audio extraction (https://toolfyra.com/video-to-audio.html) — and the privacy claim is verifiable by anyone: open DevTools, watch the Network tab, convert. Zero file bytes leave the device.

A checklist for choosing converters. If you must use a server-side tool (batch jobs, huge files), check four things before uploading anything sensitive: stated retention hours, whether the download link is authenticated, the storage jurisdiction, and whether the policy mentions filename logging. If any answer is "not stated," treat the upload as semi-public. For everyday one-file conversions, local tools remove the question entirely.

The bigger lesson. "Free" was never the price question — the price was always the file. Client-side conversion doesn't just save servers money; it moves the trust boundary from a policy page to your own machine, where it belongs. Full index of our on-device tools: https://toolfyra.com/sitemap.xml.

I Put ffmpeg in the Browser So My Servers Never See a File — Here's the Real Cost

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 19:14:10 +0000

When we moved video processing out of our servers and into the browser tab, I expected a weekend project. It was two weeks of dead ends, and the architecture lessons were worth more than the feature. Here's the honest account.

Dead end 1: SharedArrayBuffer. The 0.11-generation ffmpeg.wasm core wants SharedArrayBuffer, which demands site-wide COOP/COEP headers — and those headers silently break every third-party embed on your site. One video tool nuking your analytics iframes is a bad trade. We moved to the single-threaded 0.12 core: no SAB, no headers.

Dead end 2: CDN workers. new Worker('https://unpkg.com/...') throws SecurityError from any http origin. The blob-classURL workaround people blog about? Ignored by 0.12.10. Workers must be same-origin, period. We vendor the engine: /assets/vendor/ffmpeg/ served once, cached aggressively.

Dead end 3: UMD in a module worker. The error failed to import ffmpeg-core.js with zero detail means exactly one thing: you served the UMD core to a module worker, which does await import(coreURL) and reads .default — which UMD doesn't export. Serve the ESM core build. That's the whole fix.

The bill, honestly stated. 35 MB of vendored WASM (one-time, cached), conversion speed bound to the user's CPU, and honest UX limits — a browser merges two clips beautifully, not twenty. What you get in exchange is the property that matters: files never transmitted, never stored, never logged, because there is nowhere to transmit them to. Analytics stay anonymous; the Network tab shows zero file bytes leaving the device.

Where to see it running. The same engine powers our live tools: video compression (https://toolfyra.com/video-compressor.html), format conversion (https://toolfyra.com/video-converter.html), trimming (https://toolfyra.com/video-trimmer.html), merging (https://toolfyra.com/video-merger.html), audio extraction (https://toolfyra.com/video-to-audio.html), and audio conversion (https://toolfyra.com/audio-converter.html). Drag a file into any of them and watch the Network tab — that's the demo.

The transferable lesson. Client-side isn't a gimmick tier; for media workloads it's the privacy architecture, and the constraints it forces — vendoring, chunking, honest limits, progress events — make the product better, not worse. If you're building anything that touches user files in 2026, ask the question before you ship: does this file actually need a server? More often than not, the answer is no.

The full page index, if you want to browse everything built this way: https://toolfyra.com/sitemap.xml.

The 4,200-Page Index of Free Browser Tools That Never Upload Your Files

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 19:13:30 +0000

For two years I kept a private list of browser utilities that respected two rules: no signup walls, and no file ever leaves my machine. The list grew into a whole site — 4,200+ pages, every tool client-side — and people kept asking for "the index." This post is the index.

The rule that matters

"Free online tools" usually means "upload your file to our server, get throttled, get ads." The opposite architecture exists now: WebAssembly runs real engines — ffmpeg for video, PDF libraries for documents, crypto stacks for hashing — inside your browser tab. When conversion happens on-device, privacy isn't a policy page; it's a property you can verify in the Network tab. Everything below follows that design.

Documents & PDF — https://toolfyra.com/pdf-merger.html · https://toolfyra.com/pdf-splitter.html · https://toolfyra.com/word-to-pdf.html · https://toolfyra.com/pdf-compressor.html · https://toolfyra.com/epub-to-pdf.html

Images — https://toolfyra.com/image-compressor.html · https://toolfyra.com/image-resizer.html · https://toolfyra.com/png-to-jpg.html · https://toolfyra.com/webp-converter.html · https://toolfyra.com/qr-code-generator.html

Video & audio (on-device ffmpeg) — https://toolfyra.com/video-compressor.html · https://toolfyra.com/video-converter.html · https://toolfyra.com/video-trimmer.html · https://toolfyra.com/video-merger.html · https://toolfyra.com/audio-converter.html · https://toolfyra.com/video-to-audio.html · https://toolfyra.com/video-subtitle-generator.html

YouTube & social — https://toolfyra.com/youtube-to-mp3.html · https://toolfyra.com/youtube-to-mp4.html · https://toolfyra.com/youtube-playlist-downloader.html · https://toolfyra.com/youtube-video-summarizer.html · https://toolfyra.com/spotify-downloader.html · https://toolfyra.com/tiktok-to-mp3.html · https://toolfyra.com/instagram-reels-downloader.html

Text & writing — https://toolfyra.com/word-counter.html · https://toolfyra.com/character-counter.html · https://toolfyra.com/case-converter.html · https://toolfyra.com/lorem-ipsum-generator.html · https://toolfyra.com/ai-essay-generator.html · https://toolfyra.com/ai-story-generator.html · https://toolfyra.com/ai-email-writer.html

Calculators (the deep end) — https://toolfyra.com/bmi-calculator.html · https://toolfyra.com/age-calculator.html · https://toolfyra.com/percentage-calculator.html · https://toolfyra.com/compound-interest-calculator.html · https://toolfyra.com/mortgage-calculator.html · https://toolfyra.com/scientific-calculator.html

Security & developers — https://toolfyra.com/password-generator.html · https://toolfyra.com/md5-hash-generator.html · https://toolfyra.com/sha256-hash-generator.html · https://toolfyra.com/uuid-generator.html · https://toolfyra.com/base64-encode.html · https://toolfyra.com/json-formatter.html · https://toolfyra.com/regex-tester.html

The complete index

Categories drift; the sitemap doesn't. The full machine-readable index of every page lives at https://toolfyra.com/sitemap.xml — 4,200+ URLs, updated with each release. Bookmark it; it's the only list that never goes stale. The human-readable hub is https://toolfyra.com/, and the AI-agent-readable one is https://toolfyra.com/llms.txt.

Two closing notes. First, everything above is free with no accounts — the business model is ads on pages, never paywalls on tools. Second, if a tool here doesn't behave the way on-device promises (watch the Network tab), that's a bug report I genuinely want.

The one-line audit script that caught our worst bug: URLs serving the wrong tool

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 18:40:45 +0000

TypeScript 7's speed story is great, but this week reminded me that the cheapest correctness wins usually aren't in the compiler — they're in a 40-line script you run after every deploy.

Our bug: a deploy-tree drift meant some tool URLs served a different tool's page. Titles said one thing, canonicals said another, content was a third. 398 pages, no type error, no test failure, no build warning — every layer was individually "green".

The lesson: type systems verify structure, not agreement. Nothing in the build knew that video-merger.html should contain the string "Video Merger". So we taught it:

# audit_site.py — runs after EVERY deploy, blocks the report if it fails
for page in all_live_pages():
    html  = fetch(page.url)
    title = extract(html, "<title>")
    canon = extract(html, 'rel="canonical"')
    h1    = extract(html, "<h1>")
    assert slug_matches(page.url, title, canon, h1)  # 0 tolerance

398 pages, one HTTP sweep, under a minute. First run after the fix: 398 pages | real problems: 0. Before the fix it would have screamed.

Three rules came out of it:

The audit is a gate, not a report. It runs automatically after every deploy; a red audit blocks the "done" claim — no exceptions, no "I'll check tomorrow".
Rebuild from one truth. The drift came from two build outputs disagreeing. Now one generator, one overlay order, disk-truth sitemaps.
Log it in the open. Every task gets a START/DONE entry in a shared AGENT-LOG.md on main — with two agents (human-assisted) working the same repo, an append-only log beat every meeting we never had.

Fast compilers make iteration cheap. A 40-line agreement checker makes deploying cheap. You want both.

(Tools referenced live here: https://toolfyra.com — the audit covers all 398 of them.)

Zero-retention is an architecture decision, not a policy page

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 18:40:05 +0000

Every tool site says "we respect your privacy". Almost none can prove it, because the files you upload live on their server — even if only for seconds. "We delete it after" is a promise. Architecture is a proof.

I built a 398-tool utility site (https://toolfyra.com) on a simple rule: if a task can run client-side, the server never sees the file. Not "encrypted in transit" — never touched, period.

What that looks like in practice:

Media tools (compress, trim, merge, convert): ffmpeg compiled to WASM, running in the browser tab. Your 4 GB screen recording never leaves the device — it can't, there's no upload path in the code.
Documents (PDF merge/split, images): same pattern with WASM libraries.
The few API-backed tools (previews, metadata): only the public URL you typed is sent — never a file.
Analytics: GA4 with anonymize_ip, no user IDs, no cookie walls.

The interesting part isn't the tech, it's the constraints it forces on you:

You can't cheat on UX. Server-side tools can brute-force quality. Client-side, you budget CPU: chunking, progress events, and honest limits ("your browser can merge 2 clips, not 20").
Vendor discipline. WASM engines get vendored same-origin and version-pinned — a CDN outage can't take down your privacy story.
Your privacy policy becomes short. Mine basically says "we never receive your files" and it's true by construction, which is the kind of claim an auditor can verify in the network tab.

The EU AI Act transparency wave and watermark debates are pushing this direction anyway — users are getting literate about what leaves their machine. If your privacy answer is a policy page, start moving workloads client-side now; if it's an architecture, you already have the better story to tell.

Shipping ffmpeg.wasm 0.12 in production without SharedArrayBuffer: every dead end, mapped

Tasleem Akhtar (#Ch) — Fri, 11 Sep 2026 18:37:41 +0000

I spent a day fighting ffmpeg.wasm so you don't have to. The goal was boring: compress a video inside the browser tab, no uploads, no server bill. The journey was not.

Dead end #1 — ffmpeg.wasm 0.11. It works, until you deploy. The 0.11 core needs SharedArrayBuffer, which needs site-wide COOP/COEP headers. If your site embeds anything third-party (ads, analytics iframes, embeds), those headers silently break them. One video tool nuking your whole site's embeds is a bad trade.

Dead end #2 — cross-origin workers from a CDN. "Just load the worker from unpkg" — no. new Worker('https://unpkg.com/...') throws a SecurityError from any http origin. And the classURL blob workaround people suggest? 0.12.10 ignores it. I tried both, same afternoon.

Dead end #3 — the UMD core in a module worker. This one is sneaky. The 0.12 worker is a module worker: it tries importScripts() (undefined in modules → throws), then falls back to await import(coreURL) and reads .default. A UMD core has no default export, so you get failed to import ffmpeg-core.js with zero useful detail. The fix is one URL: serve the ESM core build, not UMD.

What actually shipped:

Vendor the ESM build same-origin: /assets/vendor/ffmpeg/ (worker, classes, const, errors, utils + esm/ffmpeg-core.js + wasm).
load({ coreURL: '/assets/vendor/ffmpeg/esm/ffmpeg-core.js', wasmURL: '.../esm/ffmpeg-core.wasm' }).
No COOP/COEP. No CDN workers. No blobs.

Total cost: 35 MB of static assets you serve once per user (aggressively cacheable), and every conversion happens on-device. Zero uploads, zero server CPU, zero retention questions.

If you want to see it working rather than read about it: I run the same engine in a browser video compressor (https://toolfyra.com/video-compressor.html), a format converter (https://toolfyra.com/video-converter.html) and an audio converter (https://toolfyra.com/audio-converter.html) — drag a file in, conversion runs in your tab, and nothing ever leaves your machine.

One last gotcha for the road: ESM import() of your vendored files resolves relative to the worker's URL. Keep the vendor directory flat and same-origin and you'll never think about it again.

The Real Price of "Free" Online Tools — We Audited What Happens to Your Files

Tasleem Akhtar (#Ch) — Fri, 04 Sep 2026 12:27:22 +0000

"Free" file tools have a business model you never see: your file. Upload-based converters quietly pay for themselves with retention — copies on disk, CDN logs, "temp" storage that isn't.

We spent months auditing this space while building Toolfyra, and turned the audit into a checklist you can use on any tool:

The 5-question audit

Does the file leave your device at all? DevTools → Network tab while converting. If a multipart upload fires, your "private" document is now their asset.
What does the privacy policy say about retention? "Deleted after 2 hours" still means 2 hours of their custody — and policies change.
Is there an account wall? Email + password for a unit converter is a data-harvesting tell.
Where do errors go? Crash reports that include filenames are a quiet leak.
Could this run locally instead? If the answer is yes (and for PDFs, audio, images it usually is), the upload is a choice, not a necessity.

The local alternative is real now

Modern browsers ship everything: crypto.subtle for hashes, Web Audio for sound, Canvas for images, wasm for the heavy stuff. Even breach-checking can be private — the k-anonymity pattern (send only the first 5 chars of a SHA-1, like our password checker does) proves you can query a leak database without revealing the password.

All 385 of our tools process on-device; the full index and every guide is in one sitemap: https://toolfyra.com/sitemap.xml

Disclosure: I run Toolfyra — but run the 5-question audit on us too. The Network tab doesn't lie.