The honest limits of browser-based file tools

We build browser-based file tools and test every one of them against the forms and specs people actually have to satisfy.

We build browser-based file tools, so this is the article arguing against our own product. It is worth writing because the alternative — letting you discover the limits halfway through something urgent — is worse for everyone.

Processing files in the browser removes the upload. It does not repeal the constraints of the formats, and it does not make a laptop into a server.

What a browser genuinely cannot do

Validated PDF/A

PDF/A is the archival standard: everything embedded, nothing external, colour spaces declared, conformance verifiable. Producing a file that claims PDF/A is easy. Producing one that passes a validator, reliably, across the documents people actually have, is not — and a document that claims conformance and fails inspection is worse than no claim.

So we do not offer it. The page exists to say so rather than to ship something that half-works. If an archive requires PDF/A, use desktop software with a validator attached.

Cryptographic signatures

Our signing tool places a picture of your signature on the page. For most purposes — an internal form, a delivery note, a landlord who wants to see a signature — that is exactly what is wanted.

It is not a digital signature: no certificate, no binding to a verified identity, no tamper-evidence. A real digital signature proves who signed and that nothing changed since. That needs a private key and usually a certificate authority. If a document is legally binding or a recipient will verify it, you need software built for that.

CMYK and print production

Browsers work in RGB. Commercial printing works in CMYK with specific profiles, and the conversion is where colour accuracy lives. We can add bleed, crop marks and the right boxes — within limits — but not produce PDF/X with proper colour separation. For anything going to a commercial press, that is a job for prepress software.

Perfect layout conversion

PDF to Word keeps fonts, sizes, colours, alignment and images for most digitally created PDFs. It is not rebuilding the original document, because the original structure is not in the PDF — a PDF describes marks on a page, not a document model. Complex multi-column layouts, tables with merged cells and floating text boxes are reconstructed by inference, and inference is sometimes wrong.

PDF to Excel is more approximate still: it detects column positions in text. Clean tabular data works well; merged cells and nested headers do not.

What is possible but constrained

Very large files

Your device does the work and your browser tab has a memory ceiling. We refuse files above roughly 150 MB because the failure beyond that is an unhelpful crash rather than a clear message, and phones run out well before laptops do. A 400-page scanned PDF on a four-year-old Android is a genuine limitation, not a pessimistic warning.

Speed on heavy work

OCR, background removal and audio noise reduction run real models. On a modern laptop that is seconds; on a budget phone it can be a minute or more. A server with a GPU will always be faster. The trade is that the file never leaves your device — worth it for a contract, not worth it for a holiday photo you are in a hurry with.

Compression that rasterises

Compressing a PDF losslessly only goes so far. Past that point the only way to get meaningfully smaller is to turn pages into images — which works, and costs you selectable text. We say which method was used, because the difference matters and is invisible on screen.

OCR in English only

Our OCR ships an English model. Other languages need their own trained data, and handwriting is not reliably readable by ordinary OCR in any language.

Browser differences

Which image formats open depends on the browser. Chrome and Edge read the most; Safari and Firefox differ around the edges, particularly on HEIC and newer formats. Occasionally the right answer is “try it in a different browser”, which is unsatisfying but true.

What local processing does not protect you from

This is the part most easily oversold, including by us, so it is worth being plain.

• Your own device. If the computer has malware, or is shared, or is a work machine with monitoring, the file is exposed there. Local processing removes the network, not the endpoint.
• What you do next. A file processed privately and then emailed is now in an email system. The protection covers one step.
• Analytics on the site itself. We count page views and tool names. That is not your file, but it is not nothing, and the privacy page lists every third party involved.
• Your browser’s own downloads. The output is saved by your browser to your device like any other download, with whatever sync or backup you have configured.

When to use something else

Why say all this

Because the claim we make — that your files are never uploaded — is only worth anything if the other things we say are also true. A site that overstates its capabilities has already told you how much its privacy promise is worth.

Every tool here carries its own limitations section, and the ones that only partly work say so on the page rather than in a footnote. One is marked unavailable rather than shipped badly. That is the same decision, written down.

How the processing works · Privacy and limits · Who builds this