How Local Processing Works

What is Local Processing?

Many online converters are upload services: files are sent to a remote server, processed there, and sent back. Local processing avoids that round trip for supported flows. Selected file contents are handled in browser memory by client-side scripts. The browser reads the file into memory once and keeps every intermediate step — decoding, resizing, re-encoding — inside that same tab, producing a downloadable result locally for supported workflows without a separate upload request in between.

Browser APIs used

ConvertUnlimited uses browser standards for supported local workflows: - HTML5 Canvas API: redraws and re-encodes images to change formats. - File & Blob APIs: handle selected files as local data streams. - Object URLs: create downloadable outputs in the browser tab. - WebAssembly (WASM): runs a compiled decoder or encoder for formats the browser has no native support for, such as HEIC, inside the same tab. - Vendored client-side libraries: support selected PDF, archive, and image operations where browser APIs need help.

Comparison: Local vs. Upload

Operational advantages and limits

For supported workflows, avoiding a server-side upload step reduces transfer time and file-exposure surface. Processing speed still depends on device CPU, available memory, browser support, and source file size. A phone with a few years-old chipset and a handful of open tabs will decode and re-encode the same file more slowly than a current desktop, and mobile browsers generally enforce tighter per-tab memory ceilings than desktop browsers, which is part of why very large files fail sooner on mobile.

Why this approach exists at all

The default pattern for free online file tools has long been upload-based: send the file to a server, wait, download the result. That pattern was set when browsers genuinely could not decode or re-encode most formats on their own. Canvas, File, Blob, and WebAssembly support have since become reliable across current browser versions for a meaningful set of everyday tasks — converting an image, resizing it, stripping metadata — which is what makes a local-only version of those specific tasks possible without giving up correctness.

When local processing does not work

Local processing is bounded by the device running it. A few situations break the model: a source file large enough that decoding it exceeds the tab's available memory, which typically surfaces as a crash or an out-of-memory error rather than a slow success; a format that neither the Canvas API nor a bundled WebAssembly decoder supports; a browser too old to support the required APIs; and a batch of many thousands of files, which a browser works through one at a time and can leave a tab unresponsive for a long stretch. For any of these, a desktop application or a server-side pipeline is the more appropriate tool.

Verifying it yourself

Related guides

How browser-based file processing works · What is WebP?

FAQ

Can ConvertUnlimited see my files?

Which version should I use for sensitive documents?

What happens if a file is too large for the browser to process?

The tab typically becomes unresponsive or the browser reports an out-of-memory error rather than completing a partial conversion. There is no server fallback for supported local-only tools, so a very large file relative to device memory is a genuine limit of this approach, not just a slow case.

Does local processing work in older browsers?

It depends on the specific APIs a tool needs. Canvas-based conversions work in most browsers from the last several years; features that rely on WebAssembly need a browser version that supports it, which is common today but was not universal a decade ago.