What is the difference between server-side and client-side PDF tools?

A server-side tool uploads your file and processes it on the operator's computers. A client-side tool sends the program to your browser and processes the file on your own device, so the file is never uploaded.

Is client-side PDF processing more private?

Yes, because there is no copy of your file anywhere except your device. A server-side tool can be well run, but you are relying on its security and retention rules for as long as it keeps the file.

Why do client-side tools struggle with very large PDFs?

The whole file has to fit in your browser tab's memory, often more than once while it's being processed. Phones and older laptops have less to spare, so a very large scan can be slow or fail. Splitting it first usually helps.

If a site loads ads, is it still client-side?

It can be. Ads, fonts and analytics are separate small requests. What matters is whether your file's contents are ever sent, which you can check in the Network tab or with the offline test.

Is Kopitiam server-side or client-side?

Kopitiam's PDF tools are client-side. They use pdf.js and pdf-lib inside your browser tab, the file is never uploaded, and the tools keep working if your connection drops after the page has loaded.

Server-side vs client-side PDF tools: how each works

A server-side PDF tool uploads your file to the operator's computers, processes it there and sends the result back. A client-side tool downloads the program to your browser instead, and the program processes the file on your own device. In the first case your document travels; in the second, only code does.

That one difference decides who can ever see your file. It also explains why the two kinds of tool feel different, fail in different ways and suit different jobs. This explainer walks through what actually happens in each, step by step.

What happens in a server-side tool

You choose a file. The page sends it over the internet to the operator's server, usually as an HTTPS upload.
The server stores it, at least on disk or in memory for the length of the job, often in a queue with other people's files.
A program on the server, such as a PDF library, a converter or a text recognition engine, does the work.
The result is stored too, and the page gives you a link to download it.
Both files are deleted later, according to the operator's own retention rules.

This used to be the only practical design. Browsers were slow, and libraries that could read and rewrite PDFs ran only on servers. Today's browsers run complex code quickly, and open-source PDF libraries written in JavaScript can do most everyday jobs inside a tab.

HTTPS protects step 1 from eavesdroppers. Steps 2 to 5 depend on the operator: their security, their staff access, their backups and their legal obligations in the country where the servers sit. Most operators handle this responsibly, but you are trusting them to.

What happens in a client-side tool

You open the tool page. Your browser downloads the page and its JavaScript, the same as any website.
You choose a file. The browser's File API reads it from your disk into the tab's memory. Nothing is sent.
Code running in the tab does the work. Heavy parts often run in a Web Worker, a background thread, so the page stays responsive.
The result is built in memory and handed to you as a download, through a temporary link that points at memory in your own browser.
When you close the tab, the memory is released. There is nothing to delete elsewhere, because nothing was sent.

Kopitiam's PDF tools work this way. They use pdf.js, the open-source PDF engine from Mozilla, to read and draw pages, with its parser running in a Web Worker. They use pdf-lib, another open-source library, to build the new PDF. Both run inside your tab.

Client-side doesn't mean the page makes no network requests. It still loads code, fonts and, on a free site, ads. What matters is that your file's bytes are never part of any request.

Why client-side tools can work offline

Once the program is in your browser, it doesn't need the network to run. That's why the offline test works: load the tool, turn off Wi-Fi, and the tool keeps going. If it really were uploading, it would fail right away.

There are details worth knowing. Kopitiam starts its PDF engine's worker as soon as a tool page opens, rather than when you drop a file, so the tools keep working if the connection drops after the page has loaded. Some less common features load extra code the first time you use them, such as the font engine for text in non-Latin scripts. That's code coming to you, not your file going out.

The real limits of client-side processing

Doing the work on your device has costs, and an honest tool should tell you about them.

Memory. The whole file sits in the tab's memory, often in more than one copy while it's being processed. A 200 MB scan can need several times that. Browsers cap memory per tab, and phones cap it hardest.
Speed. Your laptop or phone does the work, not a data centre. Rendering 400 pages to images, or recompressing every photo in a long scan, takes noticeably longer on an older device.
Battery and heat. A long job on a phone runs the processor hard for a while.
Hard jobs. Some tasks are much easier with server software, such as text recognition on large scanned archives, or converting complex Office files with exact layout. Many tools that are otherwise client-side send those particular jobs to a server.

In practice, the size limit on a client-side tool is your device rather than a number on a pricing page. Kopitiam has no file-size cap in its code, so a very large file either works or runs out of memory. Splitting a big file first, or using a desktop browser rather than a phone, usually gets it through.

Take a 40 MB scan you need to shrink for email, on a slow mobile connection. A server-side tool has to upload all 40 MB before it can start, then you download the result, so most of the wait is the network. A client-side tool skips both transfers, but your phone does the compressing itself, which can take a while for a long scan. Neither is always faster: it depends on your connection and your device.

Hybrids, and claims to read carefully

Not every tool is purely one or the other. You'll see a few patterns:

Mostly local, some server. Simple jobs run in the browser while conversion or text recognition is uploaded. Look for a per-tool statement, not a site-wide one.
Encrypted upload. The file is uploaded but encrypted in transit and at rest. That's better than nothing, but the server still decrypts it to work on it.
Local with cloud saving. The work is local, but the result is stored in your account so you can open it later. That's a server copy, by design.
Desktop apps. An installed program is client-side too, but it can also send files or usage data home. Its privacy policy still matters.

How to check which one you're using

Open the browser's developer tools (F12 on most desktop browsers), go to the Network tab and run a test file through the tool. A server-side tool shows a request roughly the size of your file going out when you start. A client-side tool shows only small requests, such as ads or analytics pings, and none that grows with your file. Doing the same job with Wi-Fi off is the quick version of the same test.

Which to choose

For contracts, payslips, medical letters and ID scans, client-side is the better default: there is no copy elsewhere to leak or keep. For a public brochure or a menu, either is fine. When you need something a browser can't do well, such as text recognition on a 2,000-page archive, a reputable server-side tool with a clear retention policy is a reasonable choice, used for that file and not as a habit.