Free PDF Tools Online

A PDF is not a document in the sense a word processor means it. It is a description of a printed page: this glyph at these coordinates, in this font, at this size. There are no paragraphs, no sentences and often no words - just characters placed where the original program decided they should sit.

That is why editing a PDF rarely behaves like editing text. Change one word and nothing reflows, because there is nothing to reflow into. It is also why the format is so reliable for sending: what you see is a fixed arrangement rather than something reassembled by whichever program opens it.

Most of the tools here work with that grain rather than against it. Merging, splitting, extracting, rotating and cropping rearrange whole pages, which is cheap and lossless because the page description is copied intact. Editing text inside a page is the expensive exception, and it is why that tool behaves more like drawing on top of the page than like typing into it.

A conventional online PDF tool is a form in front of a server. You pick a file, the browser sends it, something happens on a machine you cannot inspect, and a result comes back. That works, and it means a copy of your document existed on hardware belonging to someone else, governed by a retention policy you have to take on trust.

These tools invert that. The code that does the work - JavaScript libraries, and for heavier jobs such as compression, text recognition and passwords, engines compiled to WebAssembly - is downloaded to your browser, then the work runs on your own processor. There is no upload step, so there is no copy to retain and no policy to believe.

The trade-offs are real and worth stating plainly. Large documents use your memory rather than a server’s, so a several-hundred-megabyte file will strain an older machine in a way a server farm would not. A tool still makes network requests - for its own code, the PDF renderer and, on this site, Google’s ad scripts; merging two PDFs on 8 October 2026 made 17 of them - but none of them carries your file. And nothing syncs between devices, because nothing is stored anywhere - the file you started with is the only copy there has ever been.

A PDF can carry two different passwords and they do very different jobs. A user password encrypts the file: without it the contents cannot be read at all, by any program. An owner password only sets permissions - no printing, no copying - and the file itself is not encrypted, so any reader that chooses to ignore the flag simply will.

That distinction matters when you are deciding what to send. If a document genuinely must not be read by the wrong person, it needs a user password. If you only want to discourage casual copying, an owner password is what you want and you should not mistake it for security.

Redaction has the same gap between appearance and effect. Drawing a black rectangle over a name hides it from your eyes and leaves the text underneath, selectable and searchable by anyone who thinks to try. Removing it means removing the characters from the page, not covering them.

When a page is scanned, what gets stored is a picture of the page. It looks like text and it is not: you cannot select it, search it, or copy a sentence out of it, because as far as the file is concerned there are no letters at all - only pixels arranged in the shape of letters.

Optical character recognition reads those shapes and writes real text back into the document, positioned invisibly behind the image. The page keeps looking exactly as it did, and becomes searchable and selectable. This is why a recognised PDF is slightly larger than the scan it came from, and why the visible quality does not change.

It is also why the result is only as good as the scan. Clean, straight, reasonably high-resolution pages do well. A skewed photograph of a page taken in poor light does not, and no amount of processing invents detail that the camera did not capture.

A PDF knows where every character sits on the page. It does not know that a particular group of them is a column, because columns are not part of what the format records - they are a visual arrangement that a reader infers. Extraction has to infer them too.

Clear tables with ruled lines and consistent spacing come out cleanly, because the rules are unambiguous evidence of where one cell ends and the next begins. Tables held together by whitespace alone are a judgement call, and the judgement is sometimes wrong.

Three things are worth checking in any extracted table: merged cells, which have to be assigned to one column or split; nested headers, where a single label spans several columns; and tables that break across pages, where the header may not repeat. None of these are failures of a particular tool - they are the cost of reconstructing structure that the file never stored.