How far can you push file conversion into the browser?
Get picks like this daily. Today's launch numbers, the top launches, AI and tech news, and a daily opportunity pick, straight to your inbox.
Want to reach these readers? Sponsor an issue.
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
HN · launched Feb 19, 2026 · 5 upvotes (top 89%) · 0 views
Niche: browser-based file converters · 213 launches, 34 in the last 7 days ▲ +79% · Explore this niche →
Category and tags
- Horizontal
- Dev tools
- Developer
- Not AI
- Hobby / open-source project
More like this: all 213 launches in browser-based file converters →
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 : 717 launches clear the similarity bar, closest 8 shown.
Attention rank: #708 of 718 (itself plus its competitors, highest first, normalized so YC and Product Hunt are compared fairly).
Launched 110 days after the earliest competitor.
- FFmpeg.wasm In-Browser Video Conversion · hn · 2025-11-01 · 6 upvotes · similarity 0.56
- Docx to PDF in the Browser Using Pandoc and Typst (WASM) · hn · 2026-02-09 · 6 upvotes · similarity 0.55
- File converters and 75 tools that run in the browser · hn · 2026-03-16 · 6 upvotes · similarity 0.55
- Latex.to · hn · 2026-08-03 · 6 upvotes · similarity 0.55
- File2File · ph · 2026-10-13 · 1 upvotes · similarity 0.53
- MediaShift · ph · 2026-10-26 · 3 upvotes · similarity 0.52
- powarca · ph · 2026-10-07 · 1 upvotes · similarity 0.50
- Rudoc · hn · 2026-07-25 · 17 upvotes · similarity 0.50
The niche, labels, vibe code rating and competitor comparison on this page are analysis by Nicheloom. If you use them, please credit nicheloom.com. How you may use our data.