DEV Community: utilvo

How We Made PDF Background Removal 100% Client-Side (No Uploads, Zero Server Costs)

utilvo — Tue, 29 Sep 2026 14:27:22 +0000

As software engineers, we asked a fundamental architectural question: Why are we sending multi-megabyte user files over the wire for operations that modern browsers can execute directly in local memory?

Here is the exact engineering architecture we designed to handle vector PDF reconstruction, wallpaper eradication, and dynamic text contrast adaptation entirely inside the browser client sandbox.

The Core Technical Challenge

PDF documents are not raster images. A PDF page is an arbitrary stream of vector drawing operators (re, f, m, l), text matrix transforms (Tm, Tj), and indirect image XObjects (/Do).

When removing background elements from a PDF:

You cannot just toggle CSS opacity or apply an image filter.
You must parse the binary cross-reference table (XRef).
You have to locate the background image stream (often compressed via FlateDecode or DCTDecode).
The Critical Trap: If the original presentation used white text over a dark background, stripping the background makes the white text completely invisible on a light paper page!

1. Inspecting XObjects Locally (Zero Network Overhead)

Using client-side array buffers and WebAssembly, we read the document without ever firing an HTTP POST request:

import { PDFDocument, PDFName } from 'pdf-lib';

async function scanSlideWallpapers(pdfBytes) {
  const doc = await PDFDocument.load(pdfBytes);
  const pages = doc.getPages();
  const wallpapers = [];

  for (const page of pages) {
    const resources = page.node.Resources();
    const xObjectDict = resources?.lookup(PDFName.of('XObject'));
    if (!xObjectDict) continue;

    // Inspect stream dictionaries directly in local browser memory
    for (const [key, ref] of xObjectDict.entries()) {
      const stream = doc.context.lookup(ref);
      if (stream.dict.get(PDFName.of('Subtype'))?.name === 'Image') {
        wallpapers.push({ key: key.name, ref });
      }
    }
  }
  return wallpapers;
}

Because this execution runs inside a local Web Worker thread, a 50-page presentation parses in under 400ms on an ordinary laptop.

2. Dynamic Text Stream Inversion (Preserving Legibility)

The real breakthrough was solving text legibility. When erasing a dark background, white text (1 1 1 rg or 1 1 1 sc) vanishes against a white canvas.

We implemented an in-memory content stream parser that dynamically rewrites color operators on the fly:

// Intercepting PDF content stream operations in memory
function adaptWhiteTextForLightBackground(contentBytes) {
  let streamStr = new TextDecoder('latin1').decode(contentBytes);

  // Detect pure white or very light fill operators: 1 1 1 rg or high gray levels
  const whiteRgbPattern = /(1(?:\.0+)?\s+1(?:\.0+)?\s+1(?:\.0+)?\s+(?:rg|k|sc|scn))/gi;

  // Substitute with high-contrast readable dark tone (0.12 0.12 0.12 rg)
  const readableStream = streamStr.replace(whiteRgbPattern, '0.12 0.12 0.12 rg');

  return new TextEncoder().encode(readableStream);
}

3. Benchmarks: Client-Side vs Traditional Cloud APIs

We benchmarked a 42MB PDF containing 24 slide graphics across network types:

Architecture	Network Latency	Memory Consumption	Processing Time	Data Privacy
Cloud-Centric (Traditional)	4.2s (Upload) + 3.8s (Download)	Remote Server Cluster	~12.5s Total	Vulnerable to transit leaks
Client-Side WASM (Our Engine)	0.0s (Zero network transport)	48MB client heap	~1.4s Total	100% Private (Zero-retention)

![Zero Network Requests Proof - Utilvo Client-Side PDF Processing]
Fig 1: Chrome DevTools Network Tab during live PDF background removal on Utilvo. Notice 0 POST requests, 0 bytes uploaded, and zero outbound network activity.

We formalized these architectural benchmarks and privacy trade-offs in our peer-reviewed preprint:

Privacy-Preserving Client-Side Information Processing (DOI: 10.5281/zenodo.22975427)

How Background Removal Works in Practice (3 Dedicated Modes)

To handle the diverse realities of PDF files, we engineered three specialized processing pipelines into the engine:

Erase Wallpaper Mode (Clean Slides & Dark Presentation Themes):
Surgically eliminates heavy slide wallpapers, dark background graphics, and gradient banners. Instead of re-encoding the entire page, it targets the background XObject directly and replaces it with a clean canvas or pure white paper. This drastically reduces file size (often by 70–90%) and eliminates ink waste when printing presentation slides.
Chroma-Key Paper Cleaner (Adaptive Color Tolerance):
For documents where the background is blended into page scans, the engine calculates Euclidean color distance in local memory:
$$\Delta C = \sqrt{(\Delta R)^2 + (\Delta G)^2 + (\Delta B)^2}$$
Users can sample any tinted background color and fine-tune the tolerance slider (up to 150) to dissolve stubborn gradients, shadows, or gray scanner noise into transparent alpha channels.
Signature & Ink Extraction (Contracts & Scans):
Uses adaptive luminance thresholding to isolate dark ink signatures, hand-drawn annotations, and official stamps, stripping away paper texture with an optional monochromatic pure-black conversion toggle.

All three modes support automatic element discovery (auto-detecting the largest background graphic by surface area) with batch processing across every page in seconds.

Try the Live Implementation

We deployed this engine directly into our public utility suite. You can test the in-browser PDF background remover on your own slide decks.

Inspect your browser's DevTools Network panel while stripping backgrounds or wallpapers — you will observe zero outbound payloads leaving your device.

What's your take?

Are you migrating heavy document or media manipulation workflows from backend microservices to client-side WebAssembly? What challenges have you run into? Let's discuss in the comments below!

The Problem With Editing Private PDFs Online

utilvo — Mon, 28 Sep 2026 11:07:00 +0000

The Hidden Problem with Online PDF Editors

Editing a PDF online sounds simple: upload the file, make your changes, and download it again.

But here's the part most people don't realize: the document has to leave your computer first.

For a public flyer, this may not matter. But contracts, invoices, tax forms, IDs, financial statements, and internal company documents can contain information you may not want to send to a third-party server just to add a signature, fill out a field, or redact a number.

The good news? There's a better way!

This was one of the reasons we decided to build the PDF editor for Utilvo with browser-based processing.

Instead of uploading the document to a remote server, the editor handles the PDF directly inside your browser.

The basic difference looks like this:

Traditional approach

User
  │
  │ Upload PDF
  ▼
Remote Server
  │
  │ Process file
  ▼
Processed PDF
  │
  │ Download
  ▼
User

With local browser processing, the workflow is refreshingly different:

User
  │
  │ Select PDF
  ▼
Browser
  │
  ├── PDF.js
  ├── WebAssembly
  ├── pdf-lib
  └── Editor
  │
  ▼
Processed PDF
  │
  │ Download
  ▼
User

The beautiful idea is simple: if the browser can process the document locally, there's no need to upload the file at all.

Processing the PDF in the Browser

The first step is getting the PDF into browser memory — and it's easier than you might think!

The browser already provides the File API, so the application can read the selected file directly:

const file = input.files[0];

if (!file) return;

const buffer = await file.arrayBuffer();

At this point, the application has the PDF bytes locally. There's no upload request involved. Your file is safe right where it is.

From there, the document can be passed to the PDF rendering layer. PDF.js parses and renders PDF pages in the browser, and the editing tools work on top of the rendered document:

const loadingTask = pdfjsLib.getDocument({
  data: buffer
});

const pdf = await loadingTask.promise;

const page = await pdf.getPage(1);

The important insight here is that rendering and editing are separate problems.

PDF.js handles the rendering side. The editor layer handles text, shapes, annotations, forms, links, and other changes.

PDF Editing Is Not Just Drawing on a Canvas

Now, here's where things get really interesting — and where our approach truly shines!

A PDF is not simply an image. Text, graphics, annotations, form fields, and other elements are represented as objects and operators inside the document.

That means there's a difference between changing what the user sees and changing what actually exists inside the PDF.

For example, imagine a document contains:

Bank Account: 1234 5678 9012

A simple approach to redaction would be to draw a black rectangle over the number:

Bank Account: ███████████████

Visually, it looks correct. But here's the alarming part: if the original text still exists underneath the rectangle, the information has not really been removed. 😱

This is why proper PDF redaction needs to operate on the document content itself. Our editor handles redaction at the content-stream level by removing the underlying text operators and replacing the affected area with an opaque element.

This is the crucial difference between covering information and removing information.

Understanding PDF Content Streams

PDF pages can contain content streams with operators that describe what should be displayed. For example, text can be represented using operators such as Tj and TJ:

BT
/F1 12 Tf
(1234 5678 9012) Tj
ET

If an application only draws something on top of this content, the original text can still remain in the stream.

A redaction operation therefore needs to modify the underlying content rather than only the visual layer. This is one of the reasons a serious PDF editor needs to understand the PDF structure instead of treating every page as a flat image.

Creating Real PDF Forms — The Right Way!

Here's more good news for anyone who's ever dealt with broken "fillable" PDFs. 📋

A rectangle drawn on a PDF may look like an input field, but visually resembling a field doesn't make it an interactive PDF form field.

AcroForms use specific PDF field types:

/Tx    → Text field
/Btn   → Checkbox / Radio button
/Ch    → Choice field
/Sig   → Signature field

The editor supports these types along with other form controls such as date fields and list boxes.

A simplified text field can be represented conceptually as:

/FT /Tx
/T (FullName)
/V ()

The important part is that this becomes part of the actual PDF structure — not just a box drawn on top of the page.

When the document is exported, the form fields are written into the PDF as actual objects and associated with the document's AcroForm structure. Appearance streams are also generated so that the fields render correctly in any PDF viewer.

Adding Vector Annotations That Stay Sharp

The same principle applies to annotations. A PDF editor may need to add:

text
arrows
rectangles
circles
highlights
freehand drawings
stamps
links

These elements don't have to become screenshots. They can be represented as vector objects inside the PDF!

For example, a simple rectangle can be represented using PDF graphics operators:

q
1 0 0 1 100 200 cm
0 0 200 50 re
f
Q

The exact operators depend on the object being created, but the idea is straightforward: describe the geometry instead of turning the page into an image.

This keeps annotations razor-sharp when the document is zoomed or printed. 🖨️

The editor uses PDF transformation matrices and standard graphics operators for vector placement.

Where pdf-lib Fits

Once the document needs to be modified, the application needs a way to create and update PDF structures. This is where pdf-lib shines.

A simple example of adding text to a PDF:

const pdfDoc = await PDFDocument.load(buffer);

const page = pdfDoc.getPage(0);

page.drawText("Reviewed", {
  x: 50,
  y: 50,
  size: 12
});

const output = await pdfDoc.save();

The important part: the resulting PDF is generated from the document data rather than from a screenshot of the page.

The browser can then create a downloadable file:

const blob = new Blob([output], {
  type: "application/pdf"
});

const url = URL.createObjectURL(blob);

const link = document.createElement("a");

link.href = url;
link.download = "edited.pdf";

link.click();

URL.revokeObjectURL(url);

The entire operation happens locally. Isn't that amazing?

Why WebAssembly?

PDF processing can become expensive as documents get larger or the operations become more complex. And here's where WebAssembly comes to the rescue!

Instead of relying only on JavaScript for every operation, parts of the processing pipeline can run through WebAssembly inside the browser:

JavaScript
    │
    │ Application Logic
    ▼
WebAssembly
    │
    │ Document Processing
    ▼
PDF Data

This is one of the technologies that makes browser-based document processing genuinely practical.

The editor's workflow uses WebAssembly memory for local PDF processing rather than sending the document to a cloud processing service.

The browser is no longer just displaying the document. It's doing the actual work. 💪

Keeping the Editor State Local

There's another part of the problem that's easy to overlook.

A PDF editor has to remember what the user is doing. A user might add a text box, move it, resize it, change its properties, add a form field, rotate a page, reorder pages, and then export the document.

So the application needs an internal state that connects the rendered PDF with all these editing operations:

                 Editor State
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
     Pages       Annotations     Form Fields
       │              │              │
       └──────────────┼──────────────┘
                      ▼
               PDF Serialization
                      │
                      ▼
                 Final PDF

The editor architecture uses a client-side engine to coordinate the PDF rendering layer, interactive annotation overlays, and the PDF serialization layer.

This is why a PDF editor is more than a collection of buttons placed around a PDF viewer. There's a document state underneath the interface that has to stay synchronized with the final PDF.

The Privacy Side — The Best Part!

The main reason for keeping this processing local is privacy, and this is where the good news really delivers.

If a document is processed on a remote server, the document has to cross the network first. With local processing, the file can remain inside the browser while the user edits it.

That means there's no need for a document upload endpoint or a temporary server-side processing queue at all!

The distinction is simple:

Server Processing

PDF
 │
 ▼
Upload
 │
 ▼
Server
 │
 ▼
Process
 │
 ▼
Download

versus:

Browser Processing

PDF
 │
 ▼
Browser Memory
 │
 ├── Render
 ├── Edit
 ├── Redact
 ├── Add Forms
 └── Export
 │
 ▼
Download

Privacy, therefore, is not only a policy decision. It becomes part of the application architecture.

Of course, local processing doesn't automatically solve every security problem — the browser, extensions, third-party scripts, and the user's own device still matter. But if the document doesn't need to be uploaded in the first place, one entire part of the risk disappears completely.

The Trade-Off

Let's be honest about the challenges, because transparency matters too.

Browser-based PDF processing comes with its own hurdles:

Large documents can use a significant amount of memory
Different browsers can behave differently
PDF files can contain structures that are difficult to preserve
Exporting a modified PDF while maintaining compatibility requires more work than simply rendering the original document

These are real engineering problems. But they're problems worth solving when the alternative is uploading every document to a remote service.

For us, the goal wasn't to make every possible PDF operation run inside the browser. The goal was simpler:

If the browser can process the document locally, why send it somewhere else?

That question influenced the architecture from the very beginning.

Putting Everything Together

The complete workflow is roughly:

                         User
                          │
                          │ Select PDF
                          ▼
                 ┌─────────────────┐
                 │   Browser File  │
                 │       API       │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │     PDF.js      │
                 │   Parse/Render  │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │   Editor Layer  │
                 │                 │
                 │ Text            │
                 │ Shapes          │
                 │ Forms           │
                 │ Links           │
                 │ Redaction       │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │ pdf-lib / WASM  │
                 │ PDF Serialization│
                 └────────┬────────┘
                          │
                          ▼
                    Final PDF
                          │
                          ▼
                       Download

The PDF stays in the browser throughout the entire editing process.

If you want to see how this approach works in practice, you can try the Advanced PDF Editor directly in your browser.

Final Thoughts

PDF editing looks simple from the outside.

But once you start working with actual PDF structures, things become more interesting. There's a difference between drawing over text and removing it, between drawing a form field and creating a real AcroForm field, and between placing an image on a page and creating a native vector object.

Building all of this inside the browser adds another layer of challenges — but it also makes it possible to keep the document on the user's machine instead of sending it to a remote processing service.

That was the main idea behind this editor.

Not every PDF operation needs a server.
Sometimes, the browser is enough.

Where do you see the biggest limitations of client-side PDF processing today? Share your thoughts in the comments!

Privacy-Preserving Client-Side Processing: Rethinking Where Web Applications Handle User Data

utilvo — Sat, 26 Sep 2026 21:40:03 +0000

Privacy-Preserving Client-Side Processing: Rethinking Where Web Applications Handle User Data

Modern web applications have made it remarkably easy to upload a document, image, dataset, or other file and have a remote service process it.

That architecture is convenient, but it introduces an important question:

Does the user's data actually need to leave the device to perform the requested computation?

For many workloads, the answer is not necessarily.

Modern browsers are no longer limited to displaying HTML and executing small JavaScript interactions. They provide increasingly capable execution environments through JavaScript, Web Workers, WebAssembly, browser-native cryptographic APIs, typed binary data structures, and local storage mechanisms.

This creates an alternative architectural model:

Move suitable computation to the client and keep raw input data local whenever the task does not require centralized processing.

I recently explored this model in a research preprint titled:

Privacy-Preserving Client-Side Information Processing: A Browser-Based Architecture for Local Data Analysis and Secure File Handling

The complete research record is available through Zenodo:

DOI: https://doi.org/10.5281/zenodo.22975427

1. The traditional web processing model

A typical online file-processing application follows a relatively simple architecture:

User
  │
  │ Upload file
  ▼
Remote Server
  │
  │ Process file
  ▼
Processed result
  │
  │ Download
  ▼
User

This architecture makes sense when the application requires:

centralized databases
large server-side computation
collaboration
synchronization
server-managed state
specialized infrastructure
centralized machine learning models

But it also means the raw input has crossed a trust boundary.

Once a sensitive file is uploaded, the application operator becomes part of the data-processing environment.

Depending on the service, the data may also interact with:

server logs
temporary storage
backups
monitoring systems
third-party services
analytics infrastructure
processing queues
authentication systems

Even when an organization has strong privacy policies, the fundamental architectural fact remains:

the data was transmitted to another system.

2. What if the browser does the computation?

Consider a different architecture:

User
 │
 │ Select local file
 ▼
Browser
 │
 ├── JavaScript
 ├── Web Worker
 ├── WebAssembly
 ├── Web Cryptography
 └── Local memory
 │
 ▼
Processed result
 │
 ▼
User

The remote server may still deliver:

HTML
JavaScript
CSS
WebAssembly modules
application assets

But the actual user-provided payload does not necessarily need to be sent to the server.

This distinction is important.

The goal is not:

"The browser is automatically secure."

The goal is:

Design the data flow so that unnecessary transmission of raw user data does not occur.

3. The browser has become a computing environment

Several web platform technologies make this architecture practical.

JavaScript

JavaScript provides the application layer and can directly interact with browser APIs, files, memory buffers, workers, and cryptographic interfaces.

For many workloads, JavaScript alone is sufficient.

Web Workers

Heavy computation can be moved away from the browser's main UI thread using Web Workers.

Conceptually:

Main Thread
     │
     │ task
     ▼
Web Worker
     │
     ├── Parse
     ├── Transform
     ├── Analyze
     └── Generate result
     │
     ▼
Main Thread

This is particularly useful for workloads such as:

large document processing
image manipulation
parsing
compression
hashing
data transformation

The important architectural property is that the worker still executes inside the user's browser environment.

4. WebAssembly changes the computational boundary

WebAssembly makes it possible to execute compiled code inside modern browsers.

This is useful when an application requires computational workloads that are difficult or inefficient to implement purely in JavaScript.

A simplified architecture looks like:

Browser
│
├── JavaScript
│
├── Web Worker
│      │
│      └── WebAssembly
│             │
│             ├── Parsing
│             ├── Transformation
│             └── Computation
│
└── Local result

WebAssembly is particularly interesting for privacy-oriented applications because computation can take place inside the browser rather than automatically requiring a remote processing service.

However, WebAssembly itself is not a privacy guarantee.

The surrounding JavaScript application still controls how data enters and leaves the application.

5. Privacy is a data-flow property

One of the most important conclusions from this architectural model is that privacy should not be reduced to a checkbox saying:

"We don't store your files."

There is a fundamental difference between:

Upload
   ↓
Server
   ↓
Process
   ↓
Delete

and:

File
 ↓
Browser memory
 ↓
Process
 ↓
Result

The first architecture still requires the raw file to cross the network.

The second can avoid that transfer entirely for suitable operations.

Therefore, a more useful question is:

Where does the data physically move during processing?

This leads naturally to the concept of data-flow minimization.

6. A proposed client-side architecture

The research explores an architecture combining several browser-native technologies:

                  USER DEVICE
┌───────────────────────────────────────────────┐
│                                               │
│  ┌─────────────────┐                          │
│  │   Browser UI    │                          │
│  └────────┬────────┘                          │
│           │                                   │
│           ▼                                   │
│  ┌─────────────────┐                          │
│  │  Local File API │                          │
│  └────────┬────────┘                          │
│           │                                   │
│           ▼                                   │
│  ┌─────────────────┐                          │
│  │   Web Worker    │                          │
│  └────────┬────────┘                          │
│           │                                   │
│           ▼                                   │
│  ┌─────────────────┐                          │
│  │   WebAssembly   │                          │
│  │    Processing   │                          │
│  └────────┬────────┘                          │
│           │                                   │
│           ├───────────────┐                   │
│           ▼               ▼                   │
│      Local Result    Web Crypto               │
│                                               │
└───────────────────────────────────────────────┘

                 Network
────────────────────────────────────────────────
          No raw payload required
          for the local-processing path

The architecture can be summarized by four principles.

1. Local execution

Process the input in the browser whenever the workload permits it.

2. Isolated computation

Move computationally intensive tasks into Web Workers.

3. Efficient execution

Use WebAssembly where it provides a meaningful computational advantage.

4. Explicit data-flow boundaries

Treat network transmission as an architectural decision rather than an automatic requirement.

7. Security requires a threat model

There is an important caveat.

Client-side processing does not mean that a browser application is automatically secure.

A realistic threat model still needs to consider:

compromised browser environments
malicious browser extensions
compromised dependencies
supply-chain attacks
malicious application code
operating-system compromise
memory disclosure
browser vulnerabilities
third-party scripts
analytics
telemetry
authentication services
synchronization APIs

For example, an application could process a file locally but still send metadata or application events to an analytics endpoint.

Therefore:

Local processing
        ≠
Automatic privacy

A stronger statement is:

Local processing
        +
Controlled network behavior
        +
Auditable code
        +
Appropriate threat model
        =
Stronger privacy architecture

8. Performance: the network can become part of the computation

A major reason to investigate client-side processing is not only privacy.

Network transfer itself introduces latency.

Consider a simplified remote pipeline:

Upload
  +
Server processing
  +
Download

versus:

Local processing

For large files, the transfer component can become significant.

However, performance comparisons must be handled carefully.

The benchmark included with this research models a client-side workflow against a client-to-server-to-client workflow, including an upload/network component.

The benchmark is therefore intended to study the architectural effect of network transfer.

It is not a universal benchmark of all cloud services.

The repository includes the benchmark implementation:

GitHub repository:
https://github.com/utilvo-platform/privacy-preserving-client-side-processing

9. Benchmark results should be interpreted carefully

The research repository currently contains modeled workload comparisons for several file sizes.

The original benchmark table reports substantial latency differences between the modeled remote workflow and the local-processing workflow.

However, these numbers should not be interpreted as:

"Browser processing is always X times faster than cloud processing."

That conclusion would be too broad.

Actual performance depends on:

CPU
RAM
browser
WebAssembly engine
workload
file format
network bandwidth
network latency
server hardware
server workload
browser memory limits

A better interpretation is:

When a workload can be performed locally, eliminating the network transfer component can materially change the latency characteristics of the application.

This distinction is important for reproducible research.

10. Local processing also has limitations

Client-side computation is not a universal replacement for server-side processing.

Large workloads can encounter:

Memory limits

A browser tab cannot necessarily process arbitrarily large datasets.

CPU limitations

A server may have considerably more computational resources than a user's laptop or mobile device.

Battery consumption

Heavy local computation can consume significant power on mobile devices.

Browser compatibility

Different browsers and devices may expose different performance characteristics.

Application complexity

Some workloads require centralized state or coordination.

Security of delivered code

If the browser receives malicious JavaScript, local processing alone does not protect the user.

These constraints should be part of the architecture rather than hidden behind the phrase "privacy-first."

11. The local-first connection

Client-side processing also connects to a broader software architecture known as local-first software.

Local-first architectures emphasize keeping user data available locally and reducing unnecessary dependence on remote services.

The concept has been discussed in academic software-engineering research, including:

Local-First Software: You Own Your Data, in Spite of the Cloud

Kleppmann et al., 2019.

Research paper:

https://doi.org/10.1145/3359591.3359737

The important distinction is that local-first software and client-side processing are related but not identical concepts.

A local-first application may still synchronize data with remote systems.

Client-side processing specifically concerns where computation or data transformation occurs.

12. The research behind this architecture

The complete research paper associated with this article is:

Privacy-Preserving Client-Side Information Processing: A Browser-Based Architecture for Local Data Analysis and Secure File Handling

Author: Islam Ayoub
Year: 2026
Publication status: Preprint

Zenodo

https://doi.org/10.5281/zenodo.22975427

The Zenodo record describes the work as a preprint and explicitly states that it had not been published in a peer-reviewed journal or conference at the time of deposit.

GitHub — Research implementation

https://github.com/utilvo-platform/privacy-preserving-client-side-processing

The repository contains the research PDF, benchmark implementation, interactive demonstration, and citation metadata.

Figshare

The same research work is also archived on Figshare:

https://doi.org/10.6084/m9.figshare.34003734

Utilvo Research Documentation

https://utilvo.com/research/privacy-preserving-client-side-information-processing

13. Why this architecture matters

The interesting question is not whether browsers can execute computation.

They obviously can.

The more important architectural question is:

Which computations should remain local by default?

For certain applications, sending raw data to a remote server may be an unnecessary architectural choice rather than a technical necessity.

Examples include:

PDF manipulation
image transformations
document parsing
hashing
local data analysis
format conversion
metadata extraction
some cryptographic operations
certain machine-learning workloads

This does not mean that all of these workloads should always be client-side.

Instead, it suggests an architectural decision framework:

Does the task require centralized data?

        │
   ┌────┴────┐
   │         │
  YES        NO
   │         │
Server     Consider
processing  local processing
             │
             ▼
       Evaluate CPU,
       memory, browser,
       security and UX

14. A more precise definition of "privacy-preserving"

One lesson from this research is that privacy claims should describe observable system behavior.

Instead of:

"Your data is 100% private."

A technically meaningful claim would be:

"The application performs the specified processing locally and does not transmit the raw input payload as part of that processing path."

The second statement can potentially be tested.

A developer can inspect:

source code
browser network requests
service workers
third-party resources
Web Worker communication
application APIs

This turns privacy from a marketing statement into something closer to an architectural property that can be investigated.

15. What I am exploring next

The next stage of this research includes several areas:

reproducible cross-browser benchmarks
mobile-device evaluation
memory consumption measurements
WebAssembly versus JavaScript performance
larger document workloads
offline execution
dependency and supply-chain analysis
network-behavior verification
stronger threat modeling
reproducible security evaluation

The goal is not to claim that client-side processing solves every privacy problem.

The goal is to better understand when moving computation to the user's device provides a meaningful architectural advantage.

Conclusion

The web application architecture has traditionally been centered around a simple model:

Browser → Server → Browser

Modern browser capabilities make another model increasingly practical:

Browser
   ↓
Local computation
   ↓
Local result

For appropriate workloads, this can reduce unnecessary data transmission, eliminate network transfer from the critical processing path, and give users more direct control over where their data is processed.

But the architecture must be evaluated honestly.

Client-side processing is not synonymous with security.

WebAssembly is not synonymous with privacy.

And "no file upload" is not sufficient evidence that an entire application makes no network requests.

The meaningful engineering objective is more precise:

Minimize unnecessary data movement, make processing boundaries explicit, and verify the resulting data flow against a defined threat model.

That is the architectural direction investigated in this research.

Research & References

Research preprint:
Privacy-Preserving Client-Side Information Processing: A Browser-Based Architecture for Local Data Analysis and Secure File Handling
https://doi.org/10.5281/zenodo.22975427

Research implementation and benchmark:
https://github.com/utilvo-platform/privacy-preserving-client-side-processing

Figshare record:
https://doi.org/10.6084/m9.figshare.34003734

Local-First Software — ACM:
https://doi.org/10.1145/3359591.3359737

WebAssembly specification — W3C:
https://www.w3.org/TR/wasm-core/

Web Workers API — MDN:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API

Web Cryptography API — W3C:
https://www.w3.org/TR/WebCryptoAPI/

About the author

Islam Ayoub is an independent computer systems researcher and software architect focusing on browser-based computing, WebAssembly, privacy-preserving architectures, and local data processing.

Research presentations and technical slides:

https://speakerdeck.com/islamayoub

Lessons Learned from Building In-Browser Utilities with WebAssembly & Web Workers

utilvo — Fri, 25 Sep 2026 04:51:29 +0000

Hi everyone,

Over the past few months, I’ve been experimenting with client-side computing and wanted to share a few architectural takeaways and lessons learned from building browser-based tools without relying on a backend server.

The core idea was to explore how far modern web standards can take us when processing files (like PDF manipulation, image conversions, and cryptographic hashing) completely inside the user's browser memory.

Here are the 3 biggest technical lessons from this journey:

1. Web Workers are essential for UI responsiveness

When handling large binary files (ArrayBuffers), executing operations on the main thread causes noticeable UI lag and frame drops. Offloading heavy computational tasks to dedicated Web Workers was the single most effective way to keep the interface running smoothly at 60 FPS while background processing finishes.

2. WebAssembly (Wasm) bridges the performance gap

For tasks like document parsing or compression, pure JavaScript can sometimes struggle with throughput. Compiling native libraries to WebAssembly provided near-native execution speed directly in the browser while maintaining memory safety.

3. Native Web APIs are often underutilized

Before reaching for heavy npm packages, browser-native APIs like SubtleCrypto (Web Cryptography API) and the Canvas API proved to be extraordinarily fast for tasks like calculating SHA-256 checksums and rasterizing graphics, with zero extra bundle weight.

The biggest challenge: Memory Management

Managing memory allocation when working with large ArrayBuffers in browser RAM requires careful cleanup (garbage collection doesn't always reclaim detached buffers immediately).

For those who have worked with WebAssembly or Web Workers: How do you usually approach memory profiling and optimization in client-heavy web applications?

Would love to hear your thoughts and experiences!

Why Modern Web Apps Don't Need a Backend to Process Heavy Files Anymore

utilvo — Wed, 23 Sep 2026 18:18:48 +0000

For the past decade, a standard architectural pattern dominated web development: whenever a user needed to manipulate a file—whether merging PDFs, compressing images, calculating cryptographic checksums, or running optical character recognition—we immediately built a client-to-cloud pipeline.

The user selected a file, the frontend uploaded the 50 MB payload over a slow mobile connection to an AWS S3 bucket, a fleet of serverless Lambda functions or background EC2 instances picked it up, performed the computation, saved the result, and generated a presigned download URL.

While this pattern was necessary when browsers were relatively simple application runtimes, modern web systems can often avoid this architecture entirely.

The Silent Hardware Shift

Modern client devices have evolved into surprisingly capable computing platforms. Smartphones and developer laptops increasingly feature multi-core CPUs, high-speed memory, and GPUs capable of substantial parallel computation.

At the same time, web runtimes have standardized several technologies that make computationally intensive client-side applications practical:

WebAssembly (Wasm): Compiles languages such as C, C++, and Rust into portable bytecode that can execute at high performance inside the browser.
SIMD (Single Instruction, Multiple Data): Enables parallel processing of multiple data elements in a single CPU instruction, which can significantly accelerate image transformations and other data-intensive workloads.
Web Workers and SharedArrayBuffer: Allow expensive computations to run away from the browser's main thread, keeping the UI responsive while background processing continues.
File and Streams APIs: Provide efficient mechanisms for reading, processing, and generating large files locally without requiring every byte to travel through a remote server.

The result is a fundamental architectural shift:

The browser is no longer just a presentation layer. It can also be the compute layer.

Zero-Copy Memory Management

Historically, passing a large document between the browser's main thread and a Web Worker could introduce significant memory overhead.

With Transferable Objects, however, ownership of an ArrayBuffer can be transferred between threads without copying the underlying bytes.

For example:

// Read a file into local memory
const fileInput = document.querySelector("#fileInput");
const file = fileInput.files[0];

const arrayBuffer = await file.arrayBuffer();

// Spawn an isolated Web Worker
const worker = new Worker("processor.worker.js");

// Transfer ownership without copying the buffer
worker.postMessage(
  { buffer: arrayBuffer },
  [arrayBuffer]
);

// The ArrayBuffer is now detached from the main thread.
console.log(arrayBuffer.byteLength); // 0

Inside the worker:

self.onmessage = async (event) => {
  const { buffer } = event.data;

  const uint8View = new Uint8Array(buffer);

  // Execute the processing pipeline locally
  const resultBuffer = await executeWasmPipeline(uint8View);

  // Transfer the processed buffer back to the main thread
  self.postMessage(
    { result: resultBuffer },
    [resultBuffer]
  );
};

The important point is that the browser can move ownership of the memory between execution contexts instead of creating another full copy of the underlying data.

For large files, avoiding unnecessary memory copies can make a substantial difference to responsiveness and memory pressure.

The Mathematical Advantage: O(1) vs. O(N)

From a software economics perspective, moving computation from centralized infrastructure to the client changes the scaling model.

Centralized Cloud Processing — O(N)

In a traditional architecture, every processing request consumes some combination of:

Server CPU time
Server memory
Storage I/O
Network bandwidth
Data transfer/egress
Queue or background-worker capacity

As the number of processing requests increases, infrastructure requirements generally increase with it.

If 100,000 users simultaneously process files, the backend must have enough capacity to handle those workloads.

Client-Side Processing — Approximately O(1) for Server Compute

With a client-side architecture, the server can be responsible primarily for delivering:

HTML
JavaScript
WebAssembly modules
CSS
Static assets

These assets can be distributed through a CDN and cached close to users.

The actual file processing happens on the user's device.

So whether 10 users or 100,000 users are processing files simultaneously, the application's server-side compute workload does not scale linearly with the number of files being processed.

This does not mean the entire system literally has O(1) complexity. Client-side processing still has computational complexity based on the size of the input file.

The important distinction is that server-side compute consumption no longer needs to scale linearly with every processing request.

Zero-Data-Transit as a Security Advantage

Many file-processing applications require users to upload sensitive documents to remote infrastructure before processing them.

That creates additional security and compliance considerations.

Potential concerns include:

Network exposure: Data must travel between the user's device and remote infrastructure.
Temporary storage: Uploaded files may be temporarily stored in object storage, worker disks, caches, or processing directories.
Access control: Remote processing infrastructure must correctly enforce authentication and authorization.
Compliance requirements: Depending on the data and jurisdiction, organizations may need additional contractual, operational, and security controls.

With a genuinely client-side architecture, the original file does not need to leave the user's device.

Instead:

User's Device
     │
     ├── File
     │
     ▼
Browser Memory
     │
     ├── Web Worker
     │
     ├── WebAssembly
     │
     ▼
Processed File

There is no file upload to a processing server.

That can dramatically reduce the amount of infrastructure that has access to the user's raw data.

However, client-side processing does not automatically make an application compliant with every privacy regulation. Applications still need to consider analytics, third-party scripts, telemetry, authentication, caching, and other data flows.

The New Web Architecture

The traditional model looks like this:

                    Traditional Architecture

User
 │
 │ Upload File
 ▼
Frontend
 │
 │ HTTPS
 ▼
Cloud Storage
 │
 ▼
Backend / Workers
 │
 │ Process
 ▼
Cloud Storage
 │
 │ Download
 ▼
User

A client-side architecture can look very different:

                    Client-Side Architecture

User
 │
 ▼
Browser
 │
 ├── File API
 │
 ├── Web Worker
 │
 ├── WebAssembly
 │
 └── Local Processing
 │
 ▼
Processed File

The server's role becomes much smaller.

It can primarily distribute the application itself rather than acting as a middleman for every file operation.

What This Means for Web Developers

This architectural shift does not mean that cloud computing is obsolete.

Server-side processing remains essential for workloads that require:

Large-scale machine learning
Shared datasets
Centralized databases
Long-running jobs
Server-side authentication and authorization
Cross-device synchronization
Operations that require trusted server infrastructure

But for many file utilities, the browser can now handle workloads that previously required a backend.

Examples include:

PDF manipulation
Image compression
Image conversion
File hashing
Audio processing
Video preprocessing
OCR for suitable workloads
Document transformations
Archive inspection
Metadata extraction

The key question is no longer:

"How do we upload this file to our server?"

Instead, developers should first ask:

"Does this file actually need to leave the user's device?"

Summary

The browser has evolved from a document viewer into a powerful, sandboxed application runtime.

With technologies such as WebAssembly, Web Workers, SIMD, Transferable Objects, and modern File APIs, developers can move an increasing number of computational workloads directly to the user's device.

The resulting architecture can provide several important advantages:

Faster interaction: No mandatory upload before processing begins.
Lower infrastructure requirements: Processing CPU and memory are supplied by the client device.
Better privacy: The original file does not need to be transmitted to a processing server.
Improved scalability: Server-side compute does not have to grow linearly with every file-processing request.

The future of high-throughput web utilities is not necessarily about adding more servers.

In many cases, it is about using the computer that is already sitting in front of the user.

Building Privacy-First Web Utilities with Utilvo

utilvo — Thu, 17 Sep 2026 18:43:26 +0000

When handling sensitive documents, contracts, or personal PDFs through online tools, a critical question often goes unasked: Where does that file actually go?

Most traditional web utilities require users to upload documents to remote servers. This means confidential files travel across the network and sit in temporary processing queues on external infrastructure. For developers, professionals, and anyone handling private data, this introduces an unnecessary security vulnerability.

When designing Utilvo , the core engineering priority was clear: absolute data privacy through local, browser-based execution.

The Architecture of Privacy

Rather than routing files through external networks, Utilvo handles document processing directly inside the user's browser. By utilizing the computing power of the local hardware, tasks are executed instantly without the bottlenecks of network transfers.

The system relies on two main principles:

Zero Server Uploads: Files never leave the local machine. There is no cloud storage, no temporary staging, and no data retention on external servers.
Client-Side Execution: Document parsing, conversion, and formatting run locally, keeping confidential information completely isolated to the user's environment.

Why This Matters for Modern Workflows

Privacy should not be treated as a premium tier or an afterthought. For everyday utilities like PDF conversion, image processing, and text extraction, ensuring that data remains on the device eliminates an entire class of security risks. Building software that respects user confidentiality by default creates a faster, safer, and more reliable experience.

How do you evaluate data security when choosing online tools for your daily workflow? Let’s discuss below.

How I Built a Fast, Client-First Web Utility Platform Using Next.js and Python

utilvo — Wed, 16 Sep 2026 17:50:34 +0000

As developers, we often find ourselves needing quick file conversions, PDF merges, image compressions, or text extraction (OCR). Most existing online tools are either bloated with annoying ads, locked behind paywalls, or raise privacy concerns by handling sensitive files poorly.

A while back, I decided to build my own solution: a clean, fast, and secure web utility ecosystem. Here is a technical breakdown of how I designed and architected the platform, focusing on performance, developer experience, and lessons learned along the way.

Choosing the Tech Stack To ensure lightning-fast load times and seamless user interactions, I separated concerns between the presentation layer and heavy computational tasks:

Frontend & Routing: Next.js (React). Essential for server-side rendering (SSR), dynamic metadata management, and achieving top-tier Core Web Vitals scores.

Backend Processing: Python. Ideal for handling intensive media manipulation, document parsing, and high-precision OCR pipeline integrations.

Storage & Delivery: Cloudflare R2 and edge caching to ensure assets are delivered globally with minimal latency.

Key Architectural Challenges A. Handling File Processing Efficiently For utilities like PDF merging, image conversion, and text extraction, users expect instant feedback.

Client vs. Server Split: Lightweight tasks (like basic image cropping or format previews) run entirely client-side using modern browser APIs to save server bandwidth.

Asynchronous Pipelines: Heavy operations are offloaded to Python microservices, utilizing clean REST endpoints and handling buffers safely without blocking the main event loop.

B. Core Web Vitals & Performance
Utility sites live or die by their speed. If a user has to wait 5 seconds just for the homepage to render, they will bounce.

Code Splitting: Dynamic imports (next/dynamic) are heavily used for heavy UI components and libraries.

Minimal Dependencies: Stripped out unnecessary npm packages and built custom, lightweight helper utilities where possible to keep the JavaScript bundle footprint lean.

C. Technical SEO for Multi-Tool Platforms
When you host dozens of distinct utility tools under one roof, SEO architecture matters immensely:

Implemented clean, predictable URL routing structures (/pdf-to-word, image-compressor, etc.).

Automated dynamic JSON-LD Schema Markup injection across pages to improve search engine understanding and rich result visibility.

Lessons Learned Keep the UI out of the way: Users visiting a utility tool want to complete a task in 3 clicks or less. Clutter kills conversion and user retention.

Error Handling is King: File corruptions, unsupported formats, and oversized uploads happen constantly. Graceful error messages on the UI save hours of frustration.

Check It Out
I turned these concepts into a live project called Utilvo, where all these tools run in a unified ecosystem.

I would love to hear your thoughts, feedback, or how you approach building utility tools or micro-SaaS projects in your own stack!