Why browser-only matters for PDFs specifically.
Most PDF tools upload your file to a server, edit it there, then send it back. We don't. Here's why that single decision changes everything.
A PDF often contains the most sensitive document a person owns: a tax return, a medical record, a signed contract, a bank statement, a national ID scan. The standard SaaS workflow — upload to a third party, wait for processing, download the result — asks you to trust that company's storage policy, retention timer, audit log, sub-processors, and the integrity of every engineer with database access. For most file types that trade-off is fine. For PDFs it usually isn't.
PDFCatalyst is built on a different premise: the browser is already a capable PDF runtime. Mozilla's pdf.js renders pages to a canvas, and pdf-lib manipulates the underlying object tree — annotations, AcroForm field values, page rotation, watermarks, page numbers, splits, merges. Both run entirely in JavaScript inside your tab. Your file is loaded as a byte array in memory, edited in memory, and serialised back out as a download. The bytes never reach our infrastructure because there is no upload step in the code path.
What this means in practice
- Privacy is verifiable, not a promise. Open the browser DevTools Network tab while you edit. You will see zero outbound requests carrying your PDF. We can't leak what we never receive.
- No upload latency. A 30 MB scanned PDF that takes 8 seconds to upload to a competitor opens instantly here — the file is already on your device.
- Works offline once loaded. After the first page load the editor is cached as a service-worker asset. You can fill a tax form on a plane.
- No data-retention surface area. There is no server log, no S3 bucket, no warm cache, no backup tape that contains your document. There is nothing to subpoena.
- Free is sustainable. Server-side PDF processing is expensive (compute + bandwidth + storage). Because we do none of it for the free tier, $0 is genuinely the price — not a trial.
The honest trade-offs
Browser-only isn't a free lunch. Two real limitations: large documents (a 200-page scanned contract) consume RAM proportional to their size, because the whole file lives in memory; and OCR on image-only PDFs requires server compute that your browser doesn't have. These are exactly the cases the v1.1 paid tier handles — cloud OCR and scanned-form autofill, with explicit per-document consent and a 60-second TTL. Everything else stays client-side forever.
We're Vietnamese-first because the largest existing tools (iLovePDF, SmallPDF, PDF24) localise the UI but don't handle the long tail of Vietnamese government forms — Mẫu 02/KK-TNCN personal income tax, bảo hiểm xã hội, hợp đồng lao động — and their export pipelines often mangle diacritics. Our export path auto-fetches Roboto-Vietnamese the moment any annotation contains non-ASCII text, so "Nguyễn Thị Hằng" renders the same in the editor preview and in the exported PDF.
If you want to verify any of the above before trusting us: read the privacy policy, then open DevTools while you edit. The architecture has nothing to hide.