Most "free" PDF tools ask you to upload your document to a server, wait, and download the result. Your file — a contract, a payslip, an ID scan — passes through a machine you don't control. I wanted the same tools without that trade, so I built them to run entirely in the browser.

The site is RozKaTool (https://asaantools.pages.dev/), a collection of 46 free tools. The PDF tools — merge, split, compress, rotate, JPG to PDF, PDF to JPG, add page numbers, add watermark — all run client-side with pdf-lib and plain JavaScript. No account, no uploads, no backend at all. Here is how the pieces fit together.

Why pdf-lib

pdf-lib is a pure-JavaScript PDF library: it can create, read, and modify PDF documents without any native code. That matters because the whole site is a static site hosted on Cloudflare Pages — there is no server to run anything on, and I wanted to keep it that way. Everything ships as static files, so the site costs almost nothing to run and works even on a slow connection.

For a merge tool, the flow is short:

  1. The user picks files with an <input type="file" multiple> element.
  2. Each file is read into memory with arrayBuffer().
  3. PDFDocument.load() parses each one, copyPages() pulls the pages across, and mergedDoc.save() produces the final bytes.
  4. The result is offered as a download through a blob URL.

Nothing leaves the device. If you open the network tab while merging, you will see no request at all — the "upload" is just the browser reading a file you already have.

Keeping the UI honest about what happens

The hardest part was not the PDF code. It was making the tool feel trustworthy. A merge button that does nothing visible for three seconds looks broken, so each tool shows real progress: files listed with page counts, a status line while pages copy, and the final file size before download. No fake progress bars, no invented numbers.

The same rule applies to the whole site. The internet speed test measures against a real download, and the calculators use the actual published slabs — Pakistan's electricity tariff slabs for the bijli bill calculator, the FBR income-tax slabs for the salary tax calculator. A tool that guesses is worse than no tool at all.

What runs where

  • PDF tools: pdf-lib in the browser, as above.
  • Image tools: Canvas API — compress, resize, crop, convert, and a passport-photo maker that draws the crop on a canvas.
  • Calculators: plain JavaScript with the real slabs and rates baked in.
  • Speed test: a timed download of a generated payload, measured in the browser.

The whole site is one static build. Adding a tool means adding one folder with an index.html and a small script — no deploy pipeline beyond pushing to the Pages project.

The trade-offs of zero backend

Client-side-only has real limits, and it is worth naming them:

  • Large files are slower. A 200 MB PDF merges in your browser's memory, not on a server with 32 GB of RAM. The tools warn about very large files instead of pretending otherwise.
  • No history, no sync. Nothing is stored anywhere, so there is nothing to sync between devices. That is a privacy win and a convenience loss, and I chose privacy.
  • Old phones struggle. Heavy PDF work on a low-end phone can take a while. The tools stay usable by processing one file at a time instead of everything at once.

Try it

Everything is free and needs no sign-up: https://asaantools.pages.dev/ — the PDF tools are at /pdf-merge/, /pdf-split/, /compress-pdf/, /jpg-to-pdf/ and /pdf-to-jpg/. The bijli bill calculator is at /bijli-bill-calculator/ if you want to see a calculator built on real slabs.

If you build client-side tools too, I would like to hear how you handle the large-file case — it is the one place where "no server" genuinely hurts.