
Last week we launched Fileora (fileora.tools): 149 small tools for PDFs, images, video, audio, text and unit conversion. There is no backend, no database and no login. Every file is processed inside the browser tab and never uploaded.
That constraint was the whole point. It keeps user files private and it keeps hosting costs close to zero. It also caused most of the problems below.
The stack: Next.js 16 (App Router), strict TypeScript, Tailwind v4, shadcn/ui. The actual work is done by pdf-lib and pdfjs-dist for PDFs, ffmpeg.wasm for video and audio, tesseract.js for OCR, fflate for ZIP files, and plain Canvas helpers for images.
1. Multi-threaded FFmpeg and ad scripts cannot share a page
ffmpeg.wasm comes in two flavours. The multi-threaded core is much faster, but it needs SharedArrayBuffer, and browsers only allow that on pages that are cross-origin isolated. That means sending COOP and COEP headers.
The catch: with COEP enabled, the page refuses any cross-origin resource that has not opted in. Third-party scripts and iframes, including ad networks, stop loading. The site is meant to be ad-supported, so that was not an option.
We went with the single-threaded core. It is self-hosted and lazy loaded, so the large WebAssembly file is only downloaded when someone opens a video or audio tool. Slower encodes, but the rest of the site stays a normal web page.
2. One registry instead of 149 pages
Every tool is an entry in a single registry file and lives at /tools/[slug]. Many tools are not new code at all. "Compress image to 50 KB" is the image compressor with a preset. A variant is a component plus a preset, so adding one is mostly a content job.
Each entry also has a status. A draft tool builds and works locally but returns a 404 in production. That let us commit half-finished tools without worrying about them leaking out, and publish them in batches with a small script.
3. A translation ships only when it is complete
The site is in English, Urdu (right to left), Spanish, Portuguese and Indonesian, using a small i18n system of our own. The rule is simple: a tool appears in a language only if its long-form content and its UI strings both exist in that language.
So the counts are uneven on purpose. English has 149 tools, Urdu 87, Spanish 85, Portuguese 85, Indonesian 80. No half-translated pages, and hreflang tags only point at pages that really exist.
4. A static site can still eat your bandwidth
In the first three days the site used about 1 GB of a 10 GB monthly transfer allowance, before any real traffic arrived. Things we changed:
-
prefetch={false}on link-heavy lists. A category page with dozens of tool cards was prefetching every one of them. - Several commits per push instead of one push per commit. Each deploy has a cost.
- After a deploy we check 5 to 10 sample URLs, not the whole sitemap.
- OG image routes now list locale and slug in
generateStaticParams, so they are built once instead of on request.
Still on the list: every page ships the full registry text (about 22 KB) for search. Lazy loading that should cut transfer by a fifth or more.
5. Search data disagreed with our roadmap
We assumed the PDF tools would be the main draw. In the first week of Search Console data, the biggest group of queries was unit converters: kg to lb, cm to feet and inches, Celsius to Fahrenheit. And the leading language was Spanish, not English.
People also search for exact numbers. "23 kg to lbs" showed up again and again, which makes sense once you remember it is the standard airline baggage limit. It is tempting to generate a page for every number. We did not, because those are thin pages. The common values go into the converter page itself.
To be honest about scale: that week was roughly 1,000 impressions, 7 clicks and an average position of 38. Nobody is finding the site through search yet. But the data already told us to build converters in Spanish and Portuguese before polishing another English PDF page.
What we would like to know
If you have run multi-threaded ffmpeg.wasm on a page that also loads third-party scripts, we would like to hear how you handled the isolation headers. And if you spot a tool that breaks on your files, tell us. That is the most useful feedback we can get right now.
Top comments (0)