Client-Side Architecture

How In-Browser Local Processing Works

An in-depth explanation of how modern browser standards enable zero-upload file manipulation, audio demuxing, vector tracing, and neural background removal entirely on your local CPU and GPU.

Core Privacy Promise: Your files are processed in your browser and are not uploaded by our code. You can confirm this in your browser's Network tab. Third-party ad scripts load on the page, outside the tool area, and are not given your files.

1. The Zero-Upload Paradigm

Traditional online converter websites act as file intermediaries: you upload your high-resolution images, sensitive documents, or private video recordings to an unknown remote server cluster, wait in an arbitrary queue, and download the resulting file over the internet. This model exposes your private media to cloud storage retention, data transit breaches, and bandwidth bottlenecks.

JR LocalLab eliminates remote servers entirely. When you drag and drop a file into any workbench on this site, the file bytes are read directly into browser memory (RAM) via standard HTML5 File and Blob APIs. The computational heavy lifting—whether decoding video packets, calculating alpha transparency masks, or generating vector bezier paths—executes directly on your local device hardware.

2. How to Verify Local Processing in Your Browser

We believe privacy claims should be verifiable, not taken on faith. Anyone can confirm that their files never leave their machine using standard developer tools built into Chrome, Firefox, Safari, and Edge:

Open your browser's Developer Tools by pressing F12 or Cmd + Option + I (Mac) / Ctrl + Shift + I (Windows/Linux).
Click on the Network tab.
In the filter bar, select Fetch/XHR to isolate all data-transfer requests.
Select or drop a large video, image, or PDF into the workbench and process it.
Inspect the network log: you will notice that zero HTTP POST or PUT requests containing your file payload are dispatched. Once static assets (such as the WASM runtime or ONNX model) are loaded, processing generates zero network activity.

3. Under the Hood: The Four Browser Technologies

Running desktop-class media processing inside a webpage relies on four standardized web standards:

WebAssembly (WASM): Near-native binary code execution inside sandboxed virtual machines. We utilize single-threaded WASM compiled from C and Rust for neural inference (ONNX Runtime Web) and pure algorithms without requiring cross-origin isolation.
WebCodecs API & Demuxing: Modern browsers expose low-level hardware-accelerated decoders. By parsing container boxes (MP4/WebM) client-side, we can perform lossless stream extraction of AAC audio tracks directly into M4A containers without any quality loss or re-encoding.
Web Workers: Intensive operations like tracing vector contours or running neural networks run in background worker threads. This isolates heavy computational loops from the UI thread, ensuring smooth 60fps scrolling and responsive controls.
Canvas & OffscreenCanvas: High-performance pixel manipulation and 2D rendering enable multi-size ICO generation, procedural photo frame rendering, feathering, and color flattening in memory.

4. Memory Management & Strict Zero Storage

Our code never writes user files or derived media to localStorage, IndexedDB, Cache Storage, or cookies. All file data resides exclusively in temporary memory buffers (ArrayBuffers and TypedArrays). When you click "Clear" or navigate away, memory references are released and all generated Blob URLs are systematically revoked via URL.revokeObjectURL().