Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

How far can you push file conversion into the browser?

Details

External ID
47075166
Source
HN
Company
—
Product
—
Website domain
—
Launched
Feb. 19, 2026
Cohort
—
Upvotes
5
Upvotes percentile
0.10512129380053908
Tags
—
Fetched at
Sept. 7, 2026, 9:25 p.m.
Updated at
Sept. 7, 2026, 9:25 p.m.

Description

Hi HN,I’ve been experimenting with how much file conversion can realistically be pushed into the browser. Last year I tried compiling LibreOffice headless to WASM. The smallest build I could get was ~150MB — far too large just to convert a DOCX to PDF. That’s when I shifted to a hybrid approach. Today ~90% of conversions run client-side using WASM (FFmpeg, PDF/image tooling, spreadsheets, etc.). The heavier edge cases fall back to a small server pipeline (LibreOffice, Pandoc, Poppler).The main challenges weren’t the libraries themselves, but: browser memory ceilings handling large files without freezing the UI lazy-loading ~30MB of WASM only when needed Safari vs. Chromium behavior differencesFFmpeg.wasm runs at roughly 10–20% of native speed. Acceptable for small/medium files, less so for large media. I also experimented with multithreaded FFmpeg in the browser, but haven’t found a stable setup yet. Curious how others think about the tradeoff between client-side processing vs. fully server-side pipelines.→ anythingconverter.com

Enrichment

Theme
audio and video developer utilities
Vertical
—
Function
Dev tools
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
browser-based file conversion
Manually corrected
False

Could you build this?

No Compiling full-featured document rendering engines like LibreOffice or complex native conversion tools to WebAssembly requires deep systems engineering and toolchain compilation expertise.

What it would actually take: Building client-side document conversion requires cross-compiling massive C/C++ codebases (e.g., LibreOffice, Poppler, or HarfBuzz) to WebAssembly via Emscripten, managing memory constraints, and implementing font fallback subsystems. Alternatively, a production system uses sandboxed backend microservices running headless LibreOffice/Chromium instances orchestrated via message queues. The hard parts are WASM bundle optimization, fidelity preservation across proprietary DOCX/XLSX layouts, and efficient sandboxing.

Discussion

No comments on this launch.

Competitors

Other products that read as similar to this one — 271 launches clear the similarity bar, closest 8 shown.

Attention rank: #263 of 272 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 110 days after the earliest competitor.

Other launches for this product