When you need to compress images, you have two fundamental approaches: upload them to a server for processing, or process them locally in your browser. Most online tools - TinyPNG, Compressor.io, Squoosh.app - use server-side processing. Skwiz takes the opposite approach: everything happens locally.

Here's why that matters more than you might think.

How Server-Side Compression Works

Tools like TinyPNG work by uploading your images to remote servers where the actual compression happens. The compressed version is then downloaded back to your device. This means:

  • Your images leave your machine and travel across the internet
  • A third-party server has access to your image files
  • Processing speed depends on upload/download bandwidth
  • You're limited by API rate limits and file size caps
  • The service may retain copies of your images (check their privacy policy)

How Client-Side Compression Works

Skwiz uses Google Squoosh's WebAssembly (WASM) encoders - the same codecs used by the Squoosh web app (MozJPEG, libwebp, oxipng). These encoders run entirely in your browser:

  • Images never leave your machine
  • No upload/download wait time
  • No file size limits
  • No rate limits or quotas
  • Works offline (after initial load)
Privacy guarantee: With client-side processing, there is literally no way for your images to be seen by anyone else. The data never leaves your browser.

Speed Comparison

For a batch of 50 images (average 2MB each = 100MB total):

ApproachUploadProcessingDownloadTotal
Server-side (TinyPNG)~2 min~30s~30s~3 min
Client-side (Skwiz)0s~2 min0s~2 min

Client-side is faster for large batches because there's no network overhead. The difference grows with more images.

Quality Control

Server-side tools usually give you limited control - "compress" or "compress a lot." Client-side tools like Skwiz give you:

  • Per-image quality sliders
  • Format selection (WebP, JPEG, PNG) per image
  • Real-time preview before committing
  • Advanced codec options (effort, chroma subsampling, progressive rendering)
  • Dimension controls (resize width/height)

When Each Approach Makes Sense

Use server-side compression when:

  • You need to compress a single image quickly for a non-sensitive project
  • You're on a very low-powered device that struggles with WASM processing
  • The images are already public (e.g., compressing stock photos)

Use client-side compression when:

  • You're working with client projects or sensitive content
  • You need to batch-process dozens or hundreds of images
  • You want granular control over quality and format per-image
  • Privacy matters (design agencies, healthcare, real estate, legal)
  • You're working within a tool like Framer and want direct integration

The Technology Behind Skwiz

Skwiz bundles Google's battle-tested codecs as WebAssembly modules:

  • MozJPEG - Mozilla's optimized JPEG encoder, producing 5-15% smaller files than standard JPEG at the same quality
  • libwebp - Google's WebP encoder/decoder with full lossy and lossless support
  • oxipng - Rust-based PNG optimizer that strips unnecessary metadata and applies optimal compression

These are the same encoders used by major tech companies for production image pipelines. You get professional-grade compression without the infrastructure.

Bottom line: Client-side compression gives you better privacy, more control, and comparable speed - with zero dependence on external services.