How FileBench processes your files in the browser

The short version

• For most FileBench tools, your file is read by your browser, changed in your browser's memory and saved back to your device. It is not uploaded.
• A few steps do need a server: opening a picture your browser cannot read, saving a picture as AVIF, TIFF or BMP, and creating a share link. Each tool page lists the ones that apply to it.
• While a tool runs, your browser also sends two small records to FileBench: one describing the run and one counting usage. They carry sizes and counts, never your file or its name.
• You do not have to take any of this on trust. Your browser's developer tools show every request a page makes, and the last section shows what to look for.

Step 1: your browser reads the file

When you drop a file on a tool or pick one from your device, the browser hands the page a File object: a reference to the file on your disk. The tool reads its bytes into the page's memory when it starts. Reading a file this way is a local operation; no network request is involved.

The files you add sit in the page's own memory while you work. Nothing about them is sent anywhere just because you added them.

Step 2: the work happens inside the page

FileBench is a set of JavaScript and WebAssembly libraries that run in the page. Each kind of file has its own.

PDFs

Two libraries share the job, on purpose: one reads, the other writes.

• pdf.js reads PDFs: it draws pages (for thumbnails, previews and anything that turns a page into a picture) and pulls out text. It runs in a Web Worker, a background thread of the page, loaded from FileBench's own site. Scanned pages are often stored in compressed formats called JBIG2 and JPEG 2000; pdf.js decodes them with small WebAssembly decoders, which FileBench also serves itself, along with the colour-management module, the fonts and the character maps some PDFs need.
• pdf-lib writes PDFs (FileBench uses a maintained fork of it). Merge PDF is a good example of how it works: the tool creates a new, empty PDF, then copies the pages of each file into it in order, carrying form fields across and adding a bookmark for each file. Your originals are never changed; the result is a new file.

Pictures

The browser decodes the picture itself, the tool draws it onto a canvas (an in-memory drawing surface) and does its work there: resizing, cropping, rotating, blurring, compressing. The result is encoded again by the browser, which can write JPEG, PNG and WebP on its own.

Pictures can be very large, and a canvas that is too big for the device fails silently: it simply stays blank. So before allocating anything, FileBench works out how many pixels a job needs and keeps within fixed budgets: up to 100 million pixels for work that only draws and encodes, and 40 million for work that reads the pixels back, such as scan clean-up and text recognition. On phones, tablets and any device that reports 4 GB of memory or less, both budgets are halved. When a job would go over, the tool lowers the resolution and tells you so.

Text recognition (OCR)

FileBench uses Tesseract, an open-source OCR engine compiled to WebAssembly, running in a Web Worker. The worker and the recognition engine are served by FileBench itself. The one part that is not, at the time of writing, is the recognition model for each language: the first time you read text in a language, your browser downloads that model from tessdata.projectnaptha.com. That request is for the model only. Your picture or PDF is not part of it, and the recognition itself happens on your device. The engine keeps a copy of the model in your browser's own storage, so later runs in the same language use that copy instead of downloading it again.

Word documents and spreadsheets

A .docx file is read with Mammoth, which turns it into structured text, and Word files are written with the docx library. Spreadsheets are read and written with SheetJS. ZIP archives are handled with JSZip.

Step 3: the result comes back to you

A finished result is a file held in the page's memory. When you press Download, the page gives the browser a temporary local address for that file and asks it to save it; nothing is fetched from a server.

FileBench also keeps your recent results in your browser's own storage (IndexedDB) for 24 hours, so the History page can offer them again. That copy stays on your device and is deleted automatically, or straight away if you remove it from History.

The steps that do use a server

These are all the cases in which a file leaves your device. The same list is on the privacy page, generated from the same code, so the two cannot disagree.

1. Opening a picture your browser cannot read. Most browsers cannot open most TIFF files. FileBench first asks the browser to open the picture. Only if that fails, and only if the file's first bytes show it is a format the server can read (JPEG, PNG, GIF, WebP, TIFF or AVIF), is it sent to the server, which turns it into a PNG and sends it straight back. The rest of the work then happens in your browser as usual. iPhone HEIC photos are not sent this way: the server cannot read them either, so a HEIC file your browser cannot open is refused on your device with a message saying so.
2. Saving as AVIF, TIFF or BMP. Browsers cannot write TIFF or BMP, and some cannot write AVIF. For these, the browser first saves the finished picture as a PNG, and it is that PNG, not your original file, that goes to the server to be re-encoded. For AVIF, the browser is tried first.
3. PowerPoint and older Office formats. Laying out slides, .doc, .odt and .rtf files faithfully needs LibreOffice, which only runs on a server. At the time of writing LibreOffice is not installed on helixmedia.biz, so the tools that need it are not offered there and no tool page names this step. The code also asks the server whether the engine exists before sending a file to it.
4. Share links. Creating a share link uploads the result you chose to share, so that the person you send it to can download it. The companion guide, What happens when you upload a PDF to an online tool, walks through that path step by step.

What happens to a file on the server is short-lived by design. A picture sent for decoding or encoding is held in memory while it is worked on, and the result is streamed back to you without being kept: a BMP straight from memory, anything else through a temporary file whose name is removed as soon as it is opened. A document sent for conversion is processed in a private temporary folder that is deleted before the response finishes.

What else your browser sends while a tool runs

Apart from the page's own code, three kinds of small request go to FileBench while you use a tool:

• /api/health tells the page which server features this deployment has, so it never offers a step that cannot run.
• /api/jobs records the run: which tool, whether it ran in your browser, whether it finished or failed, the total size of the input and the result in bytes, and the number of files. For a failure it includes a short description with file names and paths replaced by the word “file”. The record carries a keyed hash of your network address, your browser's User-Agent and its language setting, not the address itself. This record is what the daily allowance is counted from: 100 operations per network address per day on helixmedia.biz at the time of writing.
• /api/events counts usage: that a tool was opened, a file added, a run started, finished or failed, a result downloaded, a share link created. It carries the event, the tool and a few numbers such as file counts, sizes and how long a run took, never names or contents. If your browser sends Do Not Track, these events are not sent at all.

On helixmedia.biz you will also see requests to Umami, the cookieless analytics service FileBench uses for page views and the same kind of counts (the script comes from cloud.umami.is and the counts go to gateway.umami.is), and requests to Google's advertising servers when a page loads Google AdSense, which funds the site. The advertising code runs beside the page and has no access to the files you process. The privacy page names the advertising domains and lists exactly what each of these services receives.

Check it yourself

1. Open a FileBench tool, for example Merge PDF.
2. Open your browser's developer tools (F12, or Cmd+Option+I on a Mac) and choose the Network tab. Clear the list.
3. Add your files and run the tool.
4. Look at what appears. For a tool that runs in your browser, you will see the small /api/jobs and /api/events requests described above, possibly some of the page's own code loading, and on helixmedia.biz the analytics and advertising requests. You will not see a request anywhere near the size of your files.
5. Click a request and open its Payload (or Request) tab to read exactly what was sent.

A request that does carry a file goes to /api/decode, /api/encode, /api/office or /api/upload, and its size is about the size of the file. If you see one of those, it is one of the cases in the list above, and the tool page will have said so before you started.

Limits worth knowing

• Your device does the work, so your device sets the limits. Very large files are bounded by your device's memory rather than by an upload limit. On a device with little memory, FileBench renders large scans at a lower resolution to stay within the halved pixel budgets described above, and says so.
• The first OCR run in a language is slower, because the language model has to download first.
• The originals are never changed. Every tool produces new files. Check each result before you rely on it, share it, or delete your original.