Blog · 6 min read

The PDF Tools That Cannot Honestly Run in a Browser

· PDFeyes Blog

Every PDF site lists roughly the same twenty tools. Some of those tools are straightforward. Others are hard, and a few cannot be done in a browser at all, which raises the question of what the ones offering them are returning to you.

What is easy

Merging, splitting, rotating, reordering, deleting pages, adding numbers or a watermark, and turning images into a PDF. All of these work by rewriting the list of pages in a file, or drawing on top of them. None requires understanding the content, so all of them are fast, lossless, and can run entirely on your own machine.

Compression: harder than it looks

Most of a large PDF's size is embedded images. compressing one means decoding those images, resampling them to a lower resolution, re-encoding them, and rebuilding the file's content streams around them.

A tool that skips that and simply rewrites the file gets you a few percent from cleaning up structure, and files that were already efficiently written come back essentially the same size. If a compressor returns a file 2% smaller and calls it done, that is what happened.

Worth knowing: your PDF reader's own "reduce file size" export usually does the real thing, because it has the image pipeline to do it with.

Password protection: real cryptography

Adding a password means encrypting the document with the PDF standard's own scheme. Removing one means decrypting it. This is not page manipulation; it is cryptography, and the widely-used browser PDF libraries do not implement it.

Which means a browser-based tool offering to add a password is either shipping a full crypto implementation, or sending your file to a server. The second is a reasonable engineering choice. It is not reasonable to describe it as running in your browser.

There is a further wrinkle on unlocking. Tools advertising password removal usually only handle owner passwords, the permission flag that restricts printing or copying, which can be stripped without knowing any secret. A user password, the one that stops the file opening at all, cannot be removed without it. Those are very different capabilities behind one button.

PDF to Word: a guess in a smart coat

A PDF does not contain paragraphs, headings, or table cells. It contains glyphs at coordinates. Converting to Word means inferring, from position alone, which characters form a word, which lines form a paragraph, where a table begins, and which text is a heading.

Good converters do this impressively well on simple layouts. On a two-column document with footnotes, or anything with a table, the output is frequently more work to repair than to retype. The conversion is not wrong so much as it is a guess, and it does not tell you where it guessed.

OCR: possible, but expensive

Reading a scanned page needs a recognition engine. These exist as browser-compatible builds, but they are several megabytes, and downloading that on every visit to make one feature work is a real cost paid by everyone who never uses it.

So it is a scheduling question rather than an impossibility, which is a different kind of honest answer than the others here.

How to tell what a tool is doing

Load it, disconnect from the internet, and use it. If it works offline, it is local. If it fails, your file was going somewhere. This takes less time than reading a privacy policy and gives a definite answer.

None of this makes server-side tools bad. Plenty of work legitimately needs a server. The problem is only the gap between what a page says and what it does, and for documents like bank statements and closing packets, that gap is worth checking.

Two things that can be done in a browser, and often are not: comparing two versions word by word, and making a scan searchable.

We list what we deliberately do not build, and why.

See all tools