Building Privacy-First Browser Tools: The Story Behind PdfPix and UTHAKKAN

The idea for PdfPix came from an ordinary annoyance rather than a market insight. Combining two PDF files is a trivial operation. It is a few hundred lines of code against a well-documented file format. Yet the experience of actually doing it on the web in 2024 meant uploading documents to a stranger's server, waiting in a queue, and being asked to create an account or watch a video before the download would unlock.

What made this irritating rather than merely inconvenient was that the hard part had already been solved. The PDF specification has been public and stable for decades. Open-source libraries that parse and rewrite it are mature and well tested. The browser had become capable enough to run them. The difficulty was entirely manufactured, and it was manufactured deliberately, because the friction was the business model.

That is the observation that started the project: a category of software where the technical problem is solved and the user experience is bad on purpose.

The obvious way to build a document tool is the conventional one. Accept an upload, process it on a server, store the result briefly, and monetise with a subscription or an advertisement. It is well understood, it scales, and it is how most competitors work.

The decision to reject that model was not primarily ideological. Server-side processing brings a specific set of obligations: you have to secure the upload, encrypt it in transit and at rest, define and enforce a retention policy, delete reliably, defend the infrastructure, and answer questions about all of it under whichever data protection regime your users fall under. For a solo developer, that is a great deal of risk attached to an operation that does not need a server at all.

Running the work in the browser eliminates the entire category. There is no upload to secure, no storage to protect, no retention policy to enforce, and no third party in the data flow. The user's document never leaves their machine, which is simultaneously the stronger privacy guarantee and the simpler engineering position.

It is worth being honest about the cost. Client-side processing means every operation has to be implementable in a browser, which rules some things out entirely and makes others considerably harder. It also means there is no server to run heavy models on, which is a real limitation and the reason the AI features on the site work differently from the rest.

Free tools generate a particular kind of feedback, and it is more useful than the feedback you get from paying customers.

People who have paid for software tend to defend the decision. They learn the interface, work around the rough edges, and report problems in terms of the product's own vocabulary. People using a free tool have no such investment. They arrive with a task, and if the tool does not complete it they leave and say exactly why. That is uncomfortable and it is exactly what you want, because it surfaces the gap between what you built and what people are actually trying to do.

The most common lesson was about the operations that matter. Feature lists suggest that users want a long menu of tools. In practice, a small number of operations account for most usage, and the quality of those operations is what determines whether the tool is used again. A merge that silently drops bookmarks is worse than no merge at all, because the user will not notice until it matters.

The second lesson was about honesty in the interface. Users notice when a claim does not match the behaviour. A privacy page that says documents are never uploaded, next to a feature that obviously requires a server, undermines trust in everything else on the site. Saying plainly what each feature does, including the ones that are less private than the rest, turns out to be a better strategy than a uniform claim that is not quite true.

PdfPix sits inside a wider set of tools built on the same principle, under the name UTHAKKAN. The common thread is not the category but the constraint: each product does something useful in the browser, without an account, and without sending the user's data anywhere it does not need to go.

ToolPix covers developer and general utilities, which is where a great deal of repetitive work lives and where a local, account-free tool is most obviously preferable to a cloud service. ZyRace explores interactive graphics in the browser, which is a different kind of stress test: it exercises rendering and input handling rather than data manipulation, and the lessons about performance port back to the other products. KallanCop is a local multiplayer game, built because a party game should not need a server or an internet connection to work.

The products share infrastructure and lessons but they are not a platform play. Each one has to be useful on its own, and none of them requires you to have an account on another. That independence is deliberate. A product family that only works together is a lock-in mechanism, and lock-in is the thing this approach is meant to avoid.

Free software still costs money to build and host, and the honest answer is that the model is a mix.

Advertising covers part of the hosting and development cost. The constraint is that advertising must not interfere with the task, which rules out interstitials, forced video, and anything that appears between selecting a file and receiving the result. Contextual advertising placed outside the workflow is the compromise.

Voluntary support from users covers another part, and the wider UTHAKKAN product set contributes. What none of it involves is charging for the core operations, gating the download, or applying a watermark. Those are the specific behaviours the project exists as a reaction to, and adopting them would make the whole exercise pointless.

The practical consequence is that growth is slower than it would be with a subscription funnel, and the product is better for it. There is no incentive to make the free tier deliberately annoying, because there is no paid tier to upgrade to.

The direction of travel is set by the browser rather than by a roadmap. As WebAssembly and WebGPU mature, operations that currently require a server become feasible locally, and each one that moves is a genuine improvement in both speed and privacy rather than a feature tick.

The honest limit is on-device machine learning. Running a capable model in a browser is possible today for narrow tasks, and the models are improving quickly, but server-class models remain ahead on complex work. The plan is to offer local inference where it is good enough and to be explicit where it is not, rather than quietly routing sensitive text through an API and calling the result private.

The other commitment is to keep the documentation honest. That means pages like the editorial policy, the methodology, and the security overview describing what the tools actually do, including the parts that are less impressive than the marketing norm. A tool that is clear about its limits is more useful than one that claims to have none.