If you’ve ever used an “online image converter”, you’ve probably had the same two concerns: privacy (do I really want to upload personal photos?) and speed (why is this taking so long?). This project exists to remove both trade‑offs by doing the work where your images already are: inside the browser.

The app is a modern image converter that runs entirely client-side. You drop in images (including iPhone HEIC/HEIF and camera RAW files), choose an output format and settings, and download the results—individually or as a ZIP. No uploads. No accounts. No waiting on a server.

Try it on Překresleno.cz.

TL;DR

  • A privacy-first image converter that runs 100% in your browser (no uploads).
  • Handles HEIC/HEIF from iPhone and extracts previews from many RAW formats.
  • Exports PNG/JPEG/WebP/AVIF (+ JPEG XL beta) and supports batch + ZIP downloads.

Překresleno.cz – format selection and settings

What the app does

  • Converts common formats (JPEG/PNG/WebP/GIF) and also handles HEIC/HEIF and RAW inputs.
  • Exports to PNG, JPEG, WebP, AVIF, and JPEG XL (beta).
  • Supports batch conversion with per-file progress, thumbnails, and a conversion summary.
  • Offers practical resize options (max resolution or max megapixels) to keep outputs lightweight.
  • Lets you control quality for lossy formats and provides an “auto” option that adapts to the input.
  • Keeps things download-friendly with single downloads or download all as ZIP.
  • Stays “privacy first”: image processing happens locally, without sending files to a backend.

How to use it (in ~30 seconds)

  1. Open the app and drop your photos onto the upload zone (or click to browse).
  2. Pick an output format (JPEG, PNG, WebP, AVIF, or JPEG XL).
  3. (Optional) Adjust quality (for lossy formats) and set a resize limit (pixels or megapixels).
  4. Click Convert, then download single files or “Download all” as a ZIP.

How it’s built (and why WebAssembly matters)

The core design goal is simple: do real image conversion in the browser, including modern codecs, without freezing the UI.

1) Client-side pipeline: decode → resize → encode

At a high level, each file goes through the same stages:

  1. Decode the input into pixels (or a browser-native representation like ImageBitmap).
  2. Resize if the user selected a target resolution/megapixel cap.
  3. Encode to the chosen output format.
  4. Produce a Blob for download (and optionally package multiple blobs into a ZIP).

2) HEIC and RAW support without servers

Some “online converters” rely on server-side tooling for HEIC and RAW. This app keeps it local:

  • HEIC/HEIF input is decoded using a libheif WebAssembly build (via heic-to / heic-decode). When the browser can’t decode HEIC natively, the WASM decoder turns the HEIC file into raw RGBA pixels that the rest of the pipeline can use.
  • RAW input is handled pragmatically: instead of full RAW demosaicing, the app uses exifr to extract the embedded preview JPEG most cameras store inside the RAW container. It’s fast, works in-browser, and is often “good enough” for sharing and quick conversions.

Překresleno.cz – batch conversion queue and download

Limitations (good to know)

  • RAW support is preview extraction, not full RAW development (no demosaicing, no tone curves, no color science controls).
  • AVIF and JPEG XL can be CPU-intensive, so big batches (or very large megapixel images) can take longer.
  • Browser support differs by format (especially AVIF/JPEG XL), and some devices may run out of memory on extremely large images.

3) Web workers keep the UI responsive

Encoding (especially AVIF/JPEG XL) can be heavy. To avoid blocking the main thread, the app pushes expensive steps into a module web worker:

  • The worker dynamically imports the encoder for the target format (WebP/AVIF/JXL/JPEG).
  • Pixel buffers are sent using transferable ArrayBuffers to reduce memory copies.
  • If worker initialization fails, the app falls back gracefully to main-thread encoding.

This separation is what makes “convert 30 photos” feel like an app instead of a frozen tab.

4) WebAssembly codecs in the browser

The key enabler is WebAssembly: codec implementations that normally live in native binaries can run safely inside the browser sandbox.

This project uses the @jsquash/* family of codecs to encode modern formats like WebP, AVIF, and JPEG XL. In practice that means:

  • You get proper codec implementations running inside the browser sandbox.
  • You don’t need a server farm for CPU-heavy work.
  • You can do sensitive conversions (personal photos, private documents) without sending data anywhere.

5) Shipping codecs as offline-capable vendor assets

WASM codecs and heavy client dependencies are prepared as local vendor bundles and cached for offline use:

  • A setup script stages codec assets into public/vendor/.
  • A service worker precaches critical app files and vendor bundles, so the app can keep working even with flaky connectivity.

The net effect is that after the first load, the converter behaves more like an installed tool than a typical website.

Quick benchmark: how formats compare

Actual results depend on content (photo vs. UI screenshot), dimensions, and quality settings, but you can still treat format choice as an optimization problem with predictable patterns.

Here’s a practical “rule-of-thumb benchmark” for a typical photo (no transparency):

Output formatTypical file sizeEncode speedBest for
JPEGBaselineFastPhotos, maximum compatibility
WebP~10–30% smaller than JPEGMediumPhotos on the web, solid support
AVIF~20–50% smaller than JPEGSlowerBest compression when you can afford time
PNGOften 2–6× larger than JPEGMediumUI graphics, screenshots, transparency, lossless needs
JPEG XL (beta)Often smaller than JPEG at similar qualitySlowerExperiments, high quality, forward-looking workflows

Which format should you choose?

  • Choose JPEG when you need maximum compatibility and fast conversions (especially for photos).
  • Choose WebP for modern web usage when you want smaller files without the slowest encode times.
  • Choose AVIF when file size matters most and you can wait a bit longer for encoding.
  • Choose PNG for screenshots, graphics, or anything with transparency (and when “lossless” matters).
  • Choose JPEG XL (beta) if you’re experimenting or you know your workflow supports it.

Conclusion: why this approach is worth it

Running conversion locally—powered by WebAssembly—brings a few concrete benefits:

  • Privacy by default: files stay on the device; there’s nothing to upload or leak.
  • Speed and scalability: your CPU does the work, so the app doesn’t slow down under load.
  • Offline-friendly: cached assets let the converter keep working without reliable network access.
  • Modern formats made accessible: WebP/AVIF/JPEG XL become one click away, even from HEIC.
  • Lower operational cost: no server-side image processing pipeline to run, secure, and scale.

In short: it’s an “online tool” that behaves like a local app—because, technically, it is.