files.co vs Stirling-PDF: hosted yourself, or just open a tab?

Most “files.co vs X” posts boil down to one thing: the other tool uploads your files and we don’t. This one is different. Stirling-PDF doesn’t upload your files either. It’s open-source, you run it on your own hardware, and the project doesn’t host any SaaS that could see your documents. If you care about privacy, Stirling-PDF is on your side.

So this isn’t a privacy fight. It’s a comparison about how much work you want to do before you can split a PDF. Let me lay it out fairly, because Stirling-PDF is genuinely good software.

What Stirling-PDF actually is

Stirling-PDF is a self-hosted PDF toolkit. It started in 2022, it’s MIT-licensed, and it’s community-driven out of the UK. You get a web interface backed by a server, with 50+ tools covering merge, split, compress, OCR, convert, sign, and a lot more. It’s one of the broadest open-source PDF catalogs out there, and the project moves fast.

The catch is in the word self-hosted. There is no stirling.com where you click a button and start working. To use it, you deploy it. That usually means Docker: pull the image, run the container, map a port, and point your browser at it. Or you set up Java and run it directly. Either way, the instance lives on a machine you provide and maintain. Your laptop, a home server, a VPS, a box at the office.

Once it’s running, files are processed on that instance and not retained by default. Encryption, TLS, access control, backups, updates: all of that is yours to configure. The project hands you the engine. You build the car around it.

Where we actually agree

It’s worth being clear about how much these two tools have in common, because it’s a lot.

Neither of us sends your documents off to some company’s cloud to be processed. With Stirling-PDF, the file stays on the instance you run. With files.co, the file never leaves your browser at all. In both cases there’s no third-party SaaS reading your contracts or invoices on the way through. Both are free. Both are built by people who think “upload your private documents to our servers” is the wrong default.

If your only question is “will a stranger’s server see my PDF,” both tools answer no. That’s the camp we share.

The real difference: a server vs a tab

Here’s where they split.

Stirling-PDF needs somewhere to live. Before you can rotate a single page, something has to be installed, configured, and kept alive. If you already run Docker and you’re comfortable with a reverse proxy and the occasional docker pull to update, that overhead is small and you barely notice it. If you don’t, it’s a real project. You’re now responsible for a service: patching it, keeping the container up, making sure the port isn’t exposed to the whole internet by accident. That’s a fine trade if you want a permanent PDF station for your team. It’s a lot if you just need to merge two files before lunch.

files.co skips all of that. The PDF engine ships inside the web page. You open files.co, pick a file, and the code that’s already loaded in the tab does the work right there on your device. Nothing to install, nothing to host, nothing to update, no container to babysit. And it’s still local: your file never gets uploaded, the same way Stirling-PDF never sends it to a company server. You can prove it. Load files.co, turn off your Wi-Fi, and run a merge anyway. It still works, because everything it needs is already on your machine.

So both keep your file private. The difference is the price of admission. Stirling-PDF asks you to stand up a server first. files.co asks you to open a tab.

Catalog and control

Credit where it’s due: Stirling-PDF has more tools. 50+ versus our 20, including some things we don’t do, like batch pipelines and certain conversions. And because you host it, you have total control. You can pin a version, audit the source, run it fully air-gapped, set your own auth and limits, and integrate it into internal systems. For an organization that wants PDF processing under its own roof with no external dependency at all, that control is the whole point, and files.co can’t match it.

files.co covers the 20 tools most people reach for day to day: merge, split, compress, rotate, watermark, protect, sign, OCR, images-to-PDF, page numbers, and the rest. All free, no account, no sign-up, capped only by your device’s memory (around 50 MB per file). It’s a web app you can install as a PWA, but there’s no server for you to own. If you need batch automation or an internal deployment you control, that’s Stirling-PDF’s turf.

So which one?

Pick Stirling-PDF if you want self-hosting and you mean it: a server you control, the widest tool catalog, the ability to audit and pin and air-gap, and a permanent PDF service for a team or an org. You’re comfortable with Docker, or you’re willing to learn, and you’d rather own the whole stack.

Pick files.co if you want to open a tab and get to work. No Docker, no VPS, no maintenance, nothing to keep alive. Your file stays on your device just like it would with Stirling-PDF, but you skip the part where you build and run the server first.

Both tools belong to the same idea: your PDFs are yours, and they shouldn’t be uploaded to anyone’s cloud to get edited. Stirling-PDF gets you there by giving you a server to run. files.co gets you there by needing no server at all. Pick the one that matches how much you want to set up before the work starts.