Girish Lade.
Web Architecture · SecurityPublished 2026-10-306 min read

Privacy by Architecture: Processing PDFs and Media on the Client Without Servers

Why uploading personal documents to remote cloud converters is an unnecessary risk, and how LS PDF and LS Image Compressor process files 100% locally in browser memory.

Every single day, millions of people upload bank statements, medical records, government identification cards, proprietary business contracts, and family photographs to “free” online file converters. They do it to solve mundane problems: merging two PDF attachments, compressing an image for a job portal, or rotating a scanned receipt.

Most users assume that once the download finishes, their document vanishes into thin air. But from an engineering standpoint, once a file hits a remote server’s file system, that guarantee is fragile. Backups are taken, temporary directories are retained, access logs capture metadata, and third-party cloud infrastructure can be probed or misconfigured.

When I designed LS PDF (pdf.ladestack.in) and LS Image Compressor (img.ladestack.in) under the LadeStack umbrella, I decided to take an uncompromising architectural stance: the best way to protect user data is to never receive it in the first place.

The Client-Side Paradigm Shift

Historically, web browsers lacked the computational muscle to parse binary formats like PDF or perform complex pixel-matrix image manipulation. Heavy processing had to be offloaded to server-side binaries like ImageMagick, Ghostscript, or Poppler.

Today, that architecture is obsolete for everyday utility operations. With JavaScript engines optimizing TypedArrays, WebAssembly executing near-native code, and the HTML5 Canvas API providing hardware-accelerated image scaling, the browser can comfortably handle document manipulation locally.

[Traditional Workflow]
User File -> Upload over WAN -> Server Disk -> Python/Java Backend -> Render -> Download WAN
(High latency, bandwidth cost, major privacy liability)

[LadeStack Architecture]
User File -> ArrayBuffer in Browser RAM -> Web Worker / Canvas API -> Local Blob URL
(Zero upload, instant execution, zero privacy exposure)

Inside LS PDF: 17 Functions in Client-Side Memory

LS PDF is built around two primary client-side libraries: PDF.js (for rendering and text extraction) and pdf-lib (for mutating, merging, splitting, and writing PDF byte streams).

1. Merging and Splitting Without Server Uploads

When you merge three PDF files in LS PDF:

  1. The user selects the files via the standard HTML5 File API.
  2. The files are read directly into memory as ArrayBuffer instances using FileReader.readAsArrayBuffer().
  3. PDFDocument.load() initializes each document inside browser memory.
  4. Selected page indices are copied into a newly instantiated document using newDoc.copyPages(sourceDoc, pageIndices).
  5. The merged document is serialized back into a Uint8Array, converted to an object URL via URL.createObjectURL(new Blob([...])), and downloaded immediately.

The entire transaction takes less than 200 milliseconds on a standard laptop. No data bytes ever traverse the network.

2. Preventing UI Lockups with Web Workers

Parsing large PDF documents with hundreds of embedded vector paths can choke the browser’s main thread. If the main thread blocks for more than 50 milliseconds, button clicks drop, scroll events stutter, and the browser displays an “Unresponsive Page” warning.

To maintain a fluid 60fps interface, LS PDF delegates all heavy operations—such as PDF text extraction, compression algorithms, and page rendering—to background Web Workers:

// Sending raw bytes to a background thread without copying
const worker = new Worker('/workers/pdf-worker.js');
const buffer = await file.arrayBuffer();

worker.postMessage({ action: 'EXTRACT_TEXT', buffer }, [buffer]);

By passing buffer as a transferable object, memory ownership moves instantly to the worker without an expensive memory copy. Once processing finishes, the worker transfers the structured output back to the main UI thread.

Inside LS Image Compressor: Direct Canvas Manipulation

For image optimization in LS Image Compressor, we bypass remote compression APIs entirely by leveraging the browser’s hardware-accelerated HTML5 Canvas API.

1. Dimension Scaling and Quality Targeting

When an image is dropped into the compressor:

  1. The file is decoded into an ImageBitmap off the main thread.
  2. We calculate target aspect-ratio dimensions to stay within the user’s maximum width/height constraints.
  3. The image is drawn onto an OffscreenCanvas using bi-cubic resampling.
  4. We call .convertToBlob({ type: 'image/webp', quality: calculatedQuality }) to produce the optimized asset.

If the user specifies an exact target file size (e.g., “compress this 4MB JPEG to under 200KB for an online portal”), the compressor uses a fast binary-search algorithm. It iterates over the compression quality factor (0.1 to 1.0) and measures the resulting byte size, converging on the ideal ratio in 3 to 4 quick passes.

2. Eliminating Third-Party Image Leaks

Many online image compressors require you to paste an image URL or upload photos. By keeping processing local, users can safely compress sensitive documents like driver’s licenses, passport scans, and proprietary design drafts directly from their clipboard (Ctrl+V) without risking data leakage.

The Economic and Ethical Advantages

Architecting web software for client-side execution creates a win-win scenario that traditional SaaS companies actively resist:

  • Zero Compute Costs for the Builder: Because processing utilizes the user’s local CPU, LadeStack does not pay for massive cloud server clusters or bandwidth bills. This allows us to keep our utilities completely free and sustainable.
  • Absolute Privacy for the User: We don’t have to write a 40-page legal privacy policy promising that we “never look at your files.” Our architecture makes it mathematically impossible for us to look at your files.
  • Offline Capability: Because the logic resides in cached JavaScript bundles, tools can be loaded once and used on the go, even with an intermittent or disconnected internet connection.

Privacy should not be an expensive premium feature sold as an enterprise add-on. By building software that respects the computational power of the browser, we can build tools that are faster, cheaper, and fundamentally safer for everyone.