PDFMergely: Building a Privacy-Focused, No-Upload PDF Tool with Browser Architecture

Every online PDF tool I tried worked the same way, pick a file, it uploads to a server, the server does the work, and you download the result. For a flyer, that is fine. But I kept needing to handle documents like contracts, payslips, and ID scans, and it felt wrong to hand those to someone else's computer just to finish a ten-second task. The moment that stuck with me was realizing the upload itself is the whole problem, not a small detail. Once a file leaves your machine, it sits in somebody's logs and backups, one breach or one quiet policy change away from leaking. Modern browsers can read the files you choose and run real processing locally, so I flipped the model. Instead of sending your file to the code, I send my code to your browser. There is no upload step because there is nowhere to upload to, and that is the entire point of PDFMergely.

What worked, launching in public and letting the privacy angle carry the conversation. My Show HN post reached 18 points and 31 comments, and the discussion itself became the marketing. Every hard question about the no upload claim was a chance to explain the architecture, and the offline test, where you load the page, turn off your wifi, and keep working, convinces more people than anything I could say. Directory listings like SaaSHub quietly became my first referring domains, and within two weeks Bing showed 11 domains linking to the site, more than double my original target of five. What flopped, AlternativeTo, the channel I assumed would be my best one. It turns out they no longer accept online PDF tools at all, so no amount of effort could fix it. My dev.to technical writeup also landed flat with zero comments. The lesson so far, live conversations beat published articles when nobody knows who you are yet.

The loudest feedback is not about features; it is about trust. On Hacker News, people assumed the design was generated by AI and asked where the GitHub repo is, and they pointed out there are no company details on the site. The design read as a template to them, when in reality I kept it deliberately simple for ease of use and had it audited by three product consultants before the public launch. That taught me something important, it does not matter what work went in if the trust signals are invisible. My answers so far, a strict Content Security Policy so the browser itself blocks any network path out, and the offline test, where you load the page, switch off your Wi-Fi, and everything keeps working, which a server-based tool cannot fake. Next, open sourcing the client code, a third-party audit, and making the craft behind the simplicity visible. The other complaint is very large files on phones, since processing uses the device's own memory, so I process documents page by page to keep it manageable.

That "we delete your files after processing" is good enough. Almost everyone, including experienced builders, assumes PDF processing needs a server, so the privacy conversation stays stuck at retention policies and promises you simply have to trust. It does not. Browsers today can merge, compress, and encrypt PDFs locally using Web Workers and WebAssembly at close to native speed, on a phone or a laptop, with no account and no infrastructure behind it. Privacy can be architecture instead of a promise. A policy can change quietly at any time, but the absence of an upload endpoint cannot be walked back without everyone noticing. The other thing people get wrong, they see hundreds of PDF sites and call the market saturated. On features, they are nearly identical, but almost none of them remove the upload entirely, and very few are finished products that handle messy real-world files well. The gap is not features. It is architecture, finish, and trust.

Open sourcing the client-side code and getting a third-party security audit because, for a no-upload claim, open code is the only proof that really settles the question. Continuing to refine the interface so the product looks as trustworthy as it already is under the hood. OCR and editing and signing, the two most requested tools from users. Possibly a Tauri desktop app, since everything already runs locally anyway. And the unglamorous SEO grind, 26 pages just got indexed on Google this week, and the first keywords beyond the brand name are starting to appear in Search Console.

202 search impressions and 58 clicks in the first month.

I came in as a working web developer, not a PDF specialist. No company, no team, and no audience. What I did have was experience shipping web apps end to end and a conviction that browsers are seriously underused as a compute platform. Everything domain-specific I learned by building, PDF internals, the quirks of form fields when documents get merged, client-side encryption, and how memory behaves when a phone tries to process a large scanned file. The rest I learned by answering hard technical questions from strangers in public threads, which turned out to be the fastest teacher of all. Starting from scratch in the domain forced me to question defaults that specialists take for granted, including the assumption that a server has to be involved at all.

Keeping the craft invisible. I kept the interface deliberately simple for ease of use and had it reviewed by three product consultants before the public launch, but I never showed any of that on the site. So when skeptical Hacker News users arrived, they assumed the design was generated by AI, asked where the repository is, and wondered who was even behind the product. Nothing was wrong with the tool, but everything about how I presented it invited doubt. For a product that asks people to hand it sensitive documents, perceived trust matters as much as real trust. The lesson, do the work and then make the work visible. An about page, the audit story, and an open repository should have been there on day one.