How PDF.Capital works

Your file never leaves your device

When you drop a PDF onto one of our tools, the browser reads it into memory using the standard File API. From that point on the document is a block of bytes inside the tab. The tool parses that block, changes it, and hands the result back to the browser as a downloadable file. At no point is an HTTP request made carrying your document, because there is nowhere for it to go: we run no conversion servers and store no user files.

The practical consequences are worth spelling out. There is no upload progress bar because there is no upload. There is no retention window to ask about, because nothing is retained. There is no server-side breach that could expose your documents, because no copy exists outside your machine. And when you close the tab, the memory holding your file is released — the work is genuinely gone.

This also means the tools keep working when your connection drops mid-task, and that a confidential contract or a medical letter can be processed without a policy decision about whether a third party is allowed to hold it.

What actually does the work

Three browser technologies do the heavy lifting. A JavaScript PDF library reads and rewrites the document structure — pages, fonts, form fields, encryption — which is how merging, splitting, rotating, numbering and protecting are done without ever re-rendering a page. A WebAssembly-compiled rendering engine draws pages to a canvas when a tool needs pixels rather than structure, which is what powers PDF to JPG, PDF to PNG, grayscale conversion and compression previews. The Canvas and Web Worker APIs then handle encoding and keep the interface responsive while a long job runs.

The distinction between structure operations and pixel operations explains a lot about the tools. Rotating a PDF changes one attribute per page, so it is instant and lossless. Converting to grayscale has to redraw every page, so it takes longer and the output is image-based. Knowing which category a tool falls into tells you what to expect from it.

Where the limits are

Running in a browser tab means working within the memory a browser will give a single page — typically a couple of gigabytes on a desktop and far less on a phone. A 300-page text document is comfortable. A 500 MB scan of an architectural drawing set is not, and the tab will run out of memory rather than finish. Speed depends on your own hardware, not on how busy our servers are, which is usually a good trade but means an old phone will be slower than a new laptop on the same file.

Some conversions are genuinely hard to do well in a browser. Turning a PDF back into an editable Word document, running optical character recognition over a scan, or producing a certified PDF/A archive all need heavyweight engines. We would rather publish nothing than publish a page that promises a conversion and then tells you to contact an administrator, so those tools are not listed until they work end to end.

What we do collect

We record anonymous usage counts — which tool was run, whether it succeeded, roughly how long it took and the file size bracket — so we know what to fix and what to build. That record contains no file, no file name and no file content. We also serve advertising, which sets cookies only after you accept them in the consent banner; before that, ad storage is denied and no ad is rendered. The full detail is in our Privacy Policy and Cookie Policy.

Why it is free

Because it costs us very little to run. There is no conversion fleet to pay for and no storage bill for user files — the compute happens on your device. Hosting a static site and a small database is cheap, and advertising covers it. That is the whole business model, and it is why there is no signup, no watermark on your output, and no daily task limit designed to push you towards a subscription.

Browse all tools or read more about who builds PDF.Capital.