How browser-local file conversion works

Most online converters upload your file to a server. Ours cannot: every tool on this site runs the conversion inside your browser, using JavaScript and WebAssembly. This page explains exactly what that means, how to check it yourself, and - just as importantly - what it makes impossible.

Why "no upload" is a real architectural difference

A server-based converter is a thin client: your browser sends the file, the server does the work, and the result comes back. That design has advantages - the server can run any library, however large - and one structural cost: the file has to exist on infrastructure you do not control, at least for a while. Retention policies, logs and backups are all outside your sight.

This site is built the other way round. There is no upload endpoint. The page loads a JavaScript library that decodes the file in memory, transforms it, and hands the result back as a local download. If the network were switched off after the page loaded, the tool would still work.

The pipeline, step by step

1. Read. The file is read with the browser's FileReader / File.arrayBuffer() APIs. It becomes bytes in the page's memory - never a request.
2. Decode. Those bytes are decoded either by the browser's own image codecs (through <img> or createImageBitmap) or by a WebAssembly library shipped for formats the browser does not support natively, such as libheif for HEIC or pdf.js for PDF pages.
3. Transform. The decoded data is drawn into a <canvas> or manipulated in memory: resized, cropped, rotated, recoloured, re-encoded.
4. Encode. The canvas is written back to a binary format with canvas.toBlob(), or a document is rebuilt with a pure-JavaScript library such as pdf-lib.
5. Deliver. The result becomes a Blob and an object URL, which the page triggers as a download. Nothing is transmitted.

How to verify it yourself

Do not take this page's word for it. Open your browser's developer tools, switch to the Network panel, and convert a file. Then look at what happened:

• You will see requests for the page, the stylesheet, the JavaScript libraries and the analytics tag - all of them by URL.
• You will not see a request whose body is your file. There is no POST with a few megabytes of payload.
• In the same panel, tick "Offline" after the page has loaded and convert again. It still works, which it could not do if a server were involved.

If you want to go further, watch the Memory or Performance tab while converting a large PDF and you will see the allocation happen in the page's own process.

What a browser does well

• Image decoding and encoding. JPEG, PNG, WebP, GIF and AVIF decode natively, and the canvas can encode most of them back.
• Pixel transforms. Resizing, cropping, rotating, compositing, colour adjustment - all hardware-assisted through the canvas API.
• PDF page rendering. pdf.js is a complete PDF renderer written in JavaScript, so a page can be turned into a canvas at any resolution.
• Document assembly. pdf-lib can create and modify PDF structures - merging, splitting, reordering, adding overlays - without rendering anything.
• Text processing. JSON, CSV, Markdown, Base64 and similar formats cost nothing to handle in JavaScript.

What a browser cannot do

Being honest about this matters more than listing capabilities, because these limits are the reason some conversions behave differently here than on a server-based tool.

• Recompress a PDF's embedded images in place. A server optimiser can decode every image inside a PDF, re-encode it more efficiently and rebuild the file with the text layer intact. In a browser this is not practical, which is why our PDF compression offers a choice: repackage the file (text stays, saving is modest) or rasterise the pages (big saving, text becomes an image).
• Encode AVIF on every browser. Creating an AVIF requires the browser's encoder, which today exists only in Chromium-based browsers. On Firefox and Safari a converter must say so rather than silently produce something else.
• Decode TIFF, or HEIC without help. Browsers do not ship these codecs, so a WebAssembly decoder has to be downloaded - roughly 600 KB for the HEIC decoder, fetched once and then cached.
• Encode GIF. Browsers decode GIF but do not encode it, so a GIF output requires a JavaScript encoder.
• OCR without a model. Reading text from a scan needs a trained recognition model of several megabytes; it is a different kind of feature, not a format conversion.
• Handle arbitrarily large files. Everything lives in the page's memory, so the practical ceiling is your device's RAM rather than a server quota. A few hundred megabytes works on a modern machine; several gigabytes does not.

Why publish the limits

A tool that claims no limits is usually hiding something. Publishing them lets you decide whether a given conversion is worth doing here at all, and it means the numbers on the tool pages - the resolution, the quality, the file size - can be checked against what the implementation actually does.

If you are writing about browser-based tools and want a citation, this page is intended for exactly that. No permission needed.

← ← Back to the tools