DEV Community: Fileora

150 file tools, zero uploads: running ffmpeg, OCR and PDF editing in the browser

Fileora — Sat, 10 Oct 2026 13:41:04 +0000

Most "free online PDF tool" sites work the same way: you upload a file, a server processes it, you download the result. That is fine for a meme. It is less fine for a passport scan, a signed contract or a bank statement.

We built Fileora the other way round. It has 150 tools for PDFs, images, video, audio and text, and no backend at all. Every file is opened, processed and saved by the browser on the user's own device. There is no upload endpoint to secure, because there is no upload.

This post is about what that takes in practice: the parts that were easy, the parts that were not, and the limits you should know about before trying the same thing.

The stack

Next.js (App Router), statically generated, hosted on a free tier
pdf-lib to edit PDF structure, pdf.js to render pages
ffmpeg.wasm for video and audio
tesseract.js for OCR
qpdf compiled to WebAssembly for PDF encryption
The Canvas API for everything image-related
fflate for ZIP downloads

None of that is exotic. The work is in how you load it and how you keep a phone from running out of memory.

Rule 1: nothing heavy loads until someone clicks

A tool page has to be a normal, fast web page. The ffmpeg core alone is about 31 MB. If that loaded with the page, nobody would stay long enough to use it.

So each tool is its own chunk, and every heavy library is imported inside the handler that needs it, never at the top of a file:

let loading: Promise<FFmpeg> | null = null

export function loadFFmpeg(onProgress = () => {}): Promise<FFmpeg> {
  loading ??= (async () => {
    const { FFmpeg } = await import("@ffmpeg/ffmpeg")
    const ffmpeg = new FFmpeg()
    const wasmURL = await fetchWithProgress("/vendor/ffmpeg/ffmpeg-core.wasm", onProgress)
    await ffmpeg.load({ classWorkerURL, coreURL, wasmURL })
    URL.revokeObjectURL(wasmURL)
    return ffmpeg
  })().catch((error) => {
    loading = null // allow a retry after a failed download
    throw error
  })
  return loading
}

Two details matter here.

Show the download. A 31 MB fetch with a spinner looks like a frozen page. We read the response body with a stream reader, count the bytes, and show a real progress bar. After the first run the core comes from the browser cache.

Reset the promise on failure. If you cache a rejected promise, one dropped connection breaks the tool until the page is reloaded.

Rule 2: single-threaded ffmpeg, on purpose

ffmpeg.wasm has a multi-threaded core that is noticeably faster. It needs SharedArrayBuffer, and browsers only expose that on cross-origin isolated pages, which means sending Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers.

Those headers also block any third-party resource that does not opt in. For a site that plans to pay its bills with ads, that is a non-starter. We use the single-threaded core and accept slower encodes.

One more ffmpeg lesson: the progress value it reports is unreliable for many inputs. We parse the Duration: line from the log output once, then divide the time field (which is in microseconds) by it. That gives a progress bar that actually reaches 100%.

Rule 3: self-host every runtime file

Workers, WebAssembly binaries, OCR language data and fonts are all served from our own domain. A small script copies them out of node_modules into public/vendor before each build:

const files = [
  [path.join(pkgDir("pdfjs-dist"), "build", "pdf.worker.min.mjs"), "pdf.worker.min.mjs"],
  ...["ffmpeg-core.js", "ffmpeg-core.wasm"].map((f) => [path.join(pkgDir("@ffmpeg/core"), "dist", "esm", f), `ffmpeg/${f}`]),
  // tesseract worker, cores and language data, qpdf, fonts…
]

This does two things. The worker file always matches the installed library version, which removes a whole class of "works locally, breaks in production" bugs. And the privacy claim stays honest: processing a file does not trigger a request to someone else's CDN.

Images: hitting an exact file size with canvas

One of the most common jobs is "make this photo under 50 KB", because application forms love that rule. Canvas gives you toBlob(callback, type, quality) but no way to ask for a size. So we search for it.

async function bestUnderTarget(canvas, format, targetBytes) {
  const floor = await canvasToBlob(canvas, format, MIN_QUALITY)
  if (floor.size > targetBytes) return null
  let best = floor, lo = MIN_QUALITY, hi = MAX_QUALITY
  for (let i = 0; i < 7; i++) {
    const mid = (lo + hi) / 2
    const blob = await canvasToBlob(canvas, format, mid)
    if (blob.size <= targetBytes) { best = blob; lo = mid } else { hi = mid }
  }
  return best
}

Seven steps of binary search over quality gets very close to the best result that fits. If even the lowest quality is too big, we step down a ladder of scales (85%, 70%, 55%…) and search again at each size. If the original already fits, we return it untouched rather than making it worse.

Three canvas traps we hit along the way:

Silent PNG fallback. Ask an older browser for WebP and it may hand you a PNG without complaining. Check blob.type against what you asked for.
Black backgrounds. JPEG has no alpha channel. Fill the canvas with white before drawing, or transparent logos come out on black.
Memory on mobile Safari. Setting canvas.width = 0 when you are done releases the bitmap memory promptly. Without it, a batch of large photos can kill the tab.

PDFs: three libraries, three jobs

pdf-lib edits structure. Merging copies pages from one document into another as they are, so text stays selectable and nothing is re-compressed.

pdf.js renders. Anything that needs to show a page (signing, cropping, converting to an image) goes through it.

Compression uses both, in two modes. The gentle mode walks the PDF's objects, finds embedded images in colour spaces it can safely convert, and re-encodes only those, leaving text and vectors alone. The aggressive mode renders each page to an image, which is what helps with scans. In both modes, if the result is not smaller, the user keeps the original.

Encryption was the surprise. pdf-lib cannot write an encrypted PDF. We compiled nothing ourselves: qpdf already exists as a WebAssembly build. Each lock or unlock job runs in a fresh worker that is terminated afterwards, so its memory is returned immediately:

const worker = new Worker(new URL("./security.worker.ts", import.meta.url), { type: "module" })
worker.postMessage(job, [job.file]) // transfer the ArrayBuffer, don't copy it

Transferring the buffer instead of copying it matters when the file is 80 MB and the device is a phone.

OCR: tell people what they are about to download

tesseract.js works well in a browser, but it needs an engine (about 4 MB) plus a data file per language (1 to 3 MB each). We ship five languages and show the first-run download size before the user starts, so nobody on mobile data is surprised.

The biggest quality win was not a model setting. Tesseract reads best when letters are around 30 pixels tall, and most screenshots are far below that. We upscale small images by up to 3× before recognition and cap very large photos at 5000 pixels on the longest side. Small cropped screenshots read much better this way.

Where browser-only hurts

It would be dishonest to stop at the wins.

Everything lives in memory. There is no streaming to disk. We warn above 100 MB, and a long video on an old phone can still fail.
Single-threaded video is slow. Trimming is quick; re-encoding a long clip is a wait.
First use costs a download. 31 MB for ffmpeg is fine on Wi-Fi and unfriendly on a metered connection.
Browsers differ. Canvas size limits, WebP encoding and HEIC decoding all vary. For HEIC we fall back to a libheif build only when the browser cannot decode the format itself.
You cannot fix a user's file for them. With no server and no logs, a bug report is "it didn't work". Error messages have to be specific, because they are the only diagnostics you get.

Was it worth it?

For this kind of product, yes. There is no processing bill that grows with usage, no file storage to secure or to delete, and the privacy promise is something a user can verify in the network tab instead of taking on trust.

The cost is that the hard problems move to the client: memory, download size and browser differences. If your users have small files and modern browsers, the trade is easy. If they have 2 GB videos, it is not.

You can try the tools at fileora.tools, and the full list is on GitHub: free-browser-tools.

If you have built something similar, we would like to hear how you handled large files. That is the part we are least happy with.

We built 149 file tools that run entirely in the browser. Here is what went wrong

Fileora — Mon, 05 Oct 2026 15:48:57 +0000

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.