We’ve all seen standard media conversion websites. You upload a sensitive PDF, a corporate DOCX, or personal photos, and they get sent to an unknown backend server somewhere in the cloud to be processed. For any developer or security-conscious user, this is a massive red flag.

I decided to fix this by building LocalForge (currently hosted as PixelForgeFree) — a 100% serverless, decentralized, client-side toolkit that handles heavy image compression, vector tracing, document compilation, and eBook reflowing right inside your browser's memory sandbox. Zero bytes leave your machine.

In this article, I’ll break down the underlying architecture, browser-native APIs, and sandboxing techniques I used to achieve this without spending a single dollar on backend infrastructure.
The Architecture: Bypassing the Cloud
To make heavy processing fluid and secure at the same time, LocalForge uses a tri-tier client execution loop:

1. In-Memory Matrix Streams (Canvas/Blob API): For light image optimization and instant format switching, everything runs synchronously via an isolated HTMLCanvasElement context directly within the main thread's RAM allocation, ensuring blazing-fast output.
2. Origin Private File System (OPFS): When handling massive multi-file queues or multi-megabyte document packages, the main thread safely stages binary chunks into a dedicated, browser-sandboxed low-level storage layout (OPFSStorage) before forwarding thread contexts.
3. Dedicated Web Worker Pools: Heavy operations — like indexing nested objects inside complex vector or binary payloads — are dynamically dispatched into isolated background threads (WorkerPool) executing сustom WASM-compiled engines. This guarantees that the browser UI never freezes, even when processing hundreds of megabytes.

Deconstructing the Engineering Core
Let’s look under the hood at how some of the 15 tools operate completely detached from the cloud:

1. In-Memory Image Compression & Transparency Preservation Instead of relying on remote server compute, LocalForge intercepts image file buffers and mounts them onto virtual layout contexts. To dynamically optimize formats like PNG or JPG into WebP next-gen streams on the fly, we utilize native toBlob allocation:

// A glance into how LocalForge processes images in RAM
const img = new Image();
img.src = URL.createObjectURL(file);
await new Promise((resolve) => (img.onload = resolve));

const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");

// Enforcing optimized viewport restrictions dynamically
let targetWidth = conversionOptions.width || img.width;
let targetHeight = img.height * (targetWidth / img.width);
canvas.width = targetWidth;
canvas.height = targetHeight;

ctx.drawImage(img, 0, 0, targetWidth, targetHeight);
URL.revokeObjectURL(img.src);

// Stream compiling into highly compressed WebP layout while maintaining alpha channels
const compressedBlob = await new Promise<Blob | null>((resolve) => {
  canvas.toBlob((b) => resolve(b), "image/webp", qualitySetting);
});

This guarantees up to 70-80% file weight reduction locally without sacrificing transparency or sending visual data across network wires.

1. Multi-Page Document Compilation via OPFS Staging When a user targets multiple images to compile them into a singular multi-page PDF document, routing individual high-res image assets through standard JavaScript memory spaces will eventually trigger an Out-Of-Memory (OOM) browser crash.

LocalForge solves this by streaming raw file data directly into OPFS:

// Securely caching binary segments locally in the browser sandbox
const storage = OPFSStorage.getInstance();
const handle = await storage.writeInboundFile(`${batchJobId}_${i}`, file);
handles.push(handle);

Once the array of atomic native handles is securely recorded, a backend-mimicking DocumentConverter thread maps the geometric boundaries of the pages, decodes raw pixel layouts step-by-step, and pipes out a clean, validated binary PDF download stream.

1. Strict Binary Architecture Parsers (PDF, Word & eBooks) One of the hardest challenges of a pure client-side architecture is handling complex typography and structural XML trees. LocalForge implements highly specialized binary bridge bridges:

• PDF to Ebook (EPUB): The application loads an isolated instance of PDF.js within a background worker to extract embedded typographic object lists, synthesizes valid binary OEBPS container layers, and wraps them instantly using an in-memory archiver fflate.
• EPUB to PDF: The system unties the compiled digital book container, merges internal XHTML chapters into a synchronized layout frame, injects custom styles, and utilizes isolated sandbox printing to render standard vector printable documents.

The Security Matrix: True Sandboxing
Because LocalForge runs entirely client-side, its security architecture is fundamentally superior to standard web converters:

• Zero Telemetry Data Storage: There are no backend loggers tracking filenames, metadata, or coordinates.
• Strict Size Enforcements: Files are verified against a secure local 500MB sandbox threshold directly on upload.
• Automatic Storage Sanitization: The application invokes a thorough system sweep on initialization, permanently wiping any temporary data descriptors residing in OPFS cache allocations.

Open Source & Contribution
LocalForge proves that modern web browsers are no longer just thin document viewers — they are incredibly powerful, secure runtime environments capable of running complex compilation pipelines locally. By moving the computing logic from the cloud directly to the user's hardware, we protect user privacy and eliminate server hosting bills.

The project is built entirely using TypeScript and Vite, ensuring a lightweight footprint and efficient production builds.

🔗 Try it live: LocalForge (PixelForgeFree)
💻 Explore the logic or star the project on GitHub: Mykhailo Sapianyi / PixelForgeFree

What are your thoughts on shifting data-heavy operations fully to the client-side browser space? Let's discuss in the comments below!