Trust Center
Local processing means the selected file is handled by JavaScript and browser APIs in the page after the static assets have loaded. For supported workflows, ConvertUnlimited does not provide a server-side upload endpoint for the processing flow.
A supported local-processing tool reads the selected file in the browser, processes it with browser APIs or vendored client-side libraries, and creates a downloadable result from the same tab.
Use the verification page, browser DevTools, and repository privacy tests to inspect the behavior instead of relying on marketing language.
A typical image workflow uses the File API to read the selected file, Canvas to decode or re-encode pixels, Blob or object URLs to hold the result, and a download link to save the new file.
PDF and developer utilities may use ArrayBuffer, Blob, Web Crypto, or vendored JavaScript libraries. The important distinction is that the file operation is performed by the browser runtime, not by a ConvertUnlimited upload service.
LOCAL_PROCESSING.md documents this as a fixed sequence: the user-selected file goes through the browser's File and Blob APIs, into tool logic written in local JavaScript, through Canvas, a PDF library, or a browser encoder, out as an object URL or generated Blob, and finally to a browser-initiated download. There is no server-side file-ingest endpoint described anywhere in that document.
Uploads are not required when the browser can decode, transform, and write the required output format locally. Examples include supported image conversion, image compression, metadata cleanup by re-encoding, many PDF operations, JSON formatting, hashing, Base64 conversion, and QR generation.
If a browser cannot decode a format, runs out of memory, or lacks an encoder for the requested output, a local-processing tool may fail or need a different workflow.
The background-remover tool's default mode is a flood-fill algorithm implemented directly in background-remover.js: it reads pixel data with canvas getImageData, compares each pixel's color distance against a sampled edge color, and writes the result back with putImageData, driven by tolerance, feather, and subject-protection sliders in the page. No external library is loaded for this default mode.
The tool also offers an optional 'AI Deep Cutout' mode, which loads an additional third-party library and downloads a model file on first use. That mode is discussed in more detail, including its size, on the Limitations page, since it changes the network behavior described on this page.
The same pattern of a small default mode plus a heavier optional mode appears elsewhere in the tool set: the PDF tools always load the pdf-lib or PDF.js library needed for their specific operation, but none of the tool families listed above depend on a runtime model download the way the AI cutout mode does.
No. The page must load static assets first. The privacy claim concerns supported processing flows after the page is loaded.
No. It depends on browser support, available memory, and the client-side libraries included in the build.
No. The page still runs inside the browser and is affected by browser, extension, device, and host behavior.
For some PDF workflows, yes. The merge, split, compress, and PDF-to-images tools state in their own FAQ content that they require a browser supporting the File API and WebAssembly.
In background-remover/background-remover.js, in the functions that build a canvas, call getImageData, compare colors, and call putImageData for the default mode.
Only its mechanism at a high level. Its network size and privacy-build behavior are covered on the Limitations page, since that mode downloads a model file rather than running against already-loaded code.
Trust documentation reviewed: May 2026. These pages describe the current public and privacy-build architecture and should be updated when deployment, telemetry, or runtime dependencies change.