This post covers the math behind ratio-based cropping, how to do it with the Canvas API in a few lines, and the practical choices you face when cropping a whole batch to one size. At the end I'll show how I handle this in zippic, the in-browser image tool I build.

Crop vs. resize vs. "fit"

Three operations get mixed up all the time:

• Crop removes pixels outside a rectangle. The aspect ratio can change; the remaining pixels are untouched.
• Resize keeps every pixel's content but changes the pixel grid (e.g. 4000×3000 → 1600×1200). The aspect ratio stays the same unless you stretch.
• Fit / fill combines the two: to turn a 4:3 photo into a 1:1 square at 1080×1080, you first crop to 1:1, then resize to 1080.

If you skip the crop and just resize 4000×3000 straight to 1080×1080, you get the classic squashed image. Every "crop to a preset" feature is really crop-then-resize.

The aspect-ratio math

Say the source is sw × sh and the target ratio is rw:rh.

function centerCropRect(sw, sh, rw, rh) {
  const target = rw / rh;
  const source = sw / sh;
  let cw, ch;
  if (source > target) {
    // source is wider than target: keep full height, trim the sides
    ch = sh;
    cw = Math.round(sh * target);
  } else {
    // source is taller (or equal): keep full width, trim top/bottom
    cw = sw;
    ch = Math.round(sw / target);
  }
  return { x: Math.round((sw - cw) / 2), y: Math.round((sh - ch) / 2), w: cw, h: ch };
}

centerCropRect(4000, 3000, 1, 1);  // { x: 500, y: 0, w: 3000, h: 3000 }
centerCropRect(4000, 3000, 16, 9); // { x: 0, y: 375, w: 4000, h: 2250 }

The crop rectangle is the largest one with the target ratio that fits inside the source. Centering it is a sensible default for batches; for single images you usually want the user to drag it.

Once you have the crop, you still need an output size. With a ratio alone (say 16:9) there are several reasonable ways to pick it:

• By width: fix the output width (e.g. 1920) and derive the height (1080).
• By height: fix the height and derive the width.
• By the smaller or larger side: useful when a batch mixes portrait and landscape files and you care about, say, "the short side should be 1080".

Rounding matters here. 1080 / (4/5) is exactly 1350, but derived values like 1000 * 9 / 16 = 562.5 are not integers. Pick one rounding rule and apply it consistently, otherwise images in the same batch can differ by a pixel.

Doing the crop with Canvas

The nine-argument form of drawImage does crop and resize in one call:

async function cropToBlob(file, rect, outW, outH, type = 'image/jpeg', quality = 0.85) {
  const bitmap = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(outW, outH);
  const ctx = canvas.getContext('2d');
  ctx.imageSmoothingQuality = 'high';
  ctx.drawImage(bitmap, rect.x, rect.y, rect.w, rect.h, 0, 0, outW, outH);
  bitmap.close();
  return canvas.convertToBlob({ type, quality });
}

A few things that bite people:

1. EXIF orientation. Phone photos are often stored sideways with an orientation flag. Current browsers apply that flag when decoding by default, but if you compute crop rectangles from the raw file's width and height you can end up cropping the wrong axis. Measure the decoded bitmap, not the file header.
2. Memory. A 4000×3000 RGBA image is about 48 MB once decoded. Decoding a whole folder at once is how tabs crash. Process files one at a time (or a few at a time in a worker) and call bitmap.close().
3. Re-encoding is lossy. Cropping is lossless in theory, but exporting a JPEG or WebP re-encodes the result. Choose the quality on purpose instead of accepting whatever the default is.
4. DPI is metadata, not pixels. A print shop that asks for "300 DPI" cares about pixel count relative to physical size. 4×6 inches at 300 DPI is 1200×1800 pixels. Canvas exports don't write a DPI value for you, so if a print workflow checks the header you need a tool that sets it.

Batch cropping: one configuration, many files

The single-image case is a UI problem (draggable rectangle, rotate, flip). The batch case is a configuration problem. When I crop a folder of product shots or social images, I want to decide:

• Fixed size or ratio? Fixed size ("every image 1200×1200") is what marketplaces and CMS templates usually want. Ratio ("every image 4:5, size derived") is better when sources vary a lot.
• Global or per-file? One setting for everything, with the option to override the odd file whose subject isn't centered.
• Output quality, so a 50-image batch doesn't silently balloon in size.

How zippic does it

zippic is a free image toolkit that runs in the browser. Its crop tools work locally, so your files are never uploaded and there's no sign-up.

Image Cropper (single image):

• Drag-to-crop, or turn on Fixed Size and type an exact width and height in pixels. The aspect-ratio lock keeps width and height proportional.
• Rotate, flip horizontally, flip vertically, and reset.
• DPI options: 72, 96, 150, 300, 600 and 1200.
• Output as JPG, WebP or AVIF, with a quality slider from 50% to 100% (75% by default). It accepts JPG, PNG and AVIF.

Bulk Image Crop (many images, one configuration):

• Fixed Size mode with presets, including Square 1:1 (1000×1000), Instagram Post (1080×1080), Instagram Story (1080×1920), Facebook Post (1200×630), Twitter Header (1500×500), LinkedIn Post (1200×627), YouTube Thumbnail (1280×720), print sizes (4×6, 5×7 and 8×10 inch, A4, A3), plus a custom width and height.
• Ratio Crop mode with 1:1, 4:3, 3:4, 16:9, 9:16, 3:2, 2:3, 5:4, 4:5, 21:9 or a custom ratio. A Size Calculation Method setting picks how the output size is derived: Auto, By Width, By Height, By Smaller Side, or By Larger Side. That's the same choice described above.
• Global Apply: switch it off to give one file its own settings.
• A before/after preview per file, a quality slider (85% by default), and Download All.
• The page recommends no more than about 50 images per batch to keep the browser responsive.

Quick checklist

• Crop to the target ratio first, then resize. Never stretch.
• Measure the decoded image, not the file header, before computing rectangles.
• Pick one rounding rule for derived sizes in a batch.
• Process big batches sequentially and free bitmaps as you go.
• Set quality deliberately when re-encoding.
• For print, think pixels = inches × DPI.

FAQ

Is cropping in the browser slower than on a server? For typical photos, decode, crop and encode take far less time than uploading and downloading the file. The limit is device memory, which is why batches should be processed in chunks.

Does cropping reduce quality? The kept pixels aren't changed, but saving as JPG, WebP or AVIF re-encodes them. Use a higher quality setting for images you'll edit again.

Why does my batch have different sizes? You're probably using ratio mode with mixed portrait and landscape sources. Use fixed size, or derive the size from a consistent side.

I'm the developer of zippic. If you try the cropper or bulk crop on real-world files and something behaves unexpectedly, I'd really like to hear about it in the comments.

The good news: in 2026 the format question is much simpler than it was a few years ago. WebP and AVIF are both supported by every major modern browser, so the old "but Safari doesn't support it" worry is mostly gone. The question now is less "can I use it?" and more "which one fits this image?"

This guide compares JPEG, WebP and AVIF (plus a quick word on PNG and GIF), explains when to use each, and walks through a practical workflow for converting and compressing your site's images, including how to do it entirely in your browser without uploading files to anyone's server.

The quick comparison

Exact savings depend heavily on the image. A noisy photo, a flat illustration and a screenshot full of text all compress differently, so treat any "X% smaller" claim you read online, including vague ones like the above, as a starting hypothesis to test on your own images.

When to use each format

Use AVIF when file size matters most

AVIF is based on the AV1 video codec and is generally the most efficient of the three for photographs. It shines on large hero images, product photos and image-heavy galleries, where shaving bytes has a real effect on load time. It also handles smooth gradients well at low quality settings, where JPEG tends to show banding and blocky artifacts.

The trade-offs:

• Encoding is slow. For a handful of images that doesn't matter. For thousands of images in a build pipeline it can, so pick a moderate speed/effort setting.
• Very fine detail can soften. At aggressive settings AVIF tends to smooth textures rather than produce JPEG-style blocks. That usually looks better, but check images with fine text or hair-like detail.
• Some non-browser software still lags. Older image editors, CMS plugins, or social media platforms may not accept AVIF uploads.

Use WebP as your safe, all-round default

WebP is the pragmatic choice. It compresses better than JPEG, supports transparency and animation, encodes quickly, and is accepted by most tools and platforms today. If you want one format for everything and don't want to think too hard, WebP is it.

WebP is particularly good for:

• Images with transparency: logos, product cutouts and UI elements that would otherwise be large PNGs.
• Screenshots and graphics: WebP lossless often beats PNG on file size.
• Animations: an animated WebP is usually far smaller than the equivalent GIF.

Use JPEG when compatibility beats everything

JPEG isn't dead. It's still the right choice when the image leaves the browser: email newsletters (many email clients have patchy support for newer formats), files you're handing to clients, uploads to platforms that recompress anyway, and as the final fallback in a <picture> element. Modern encoders like MozJPEG also squeeze noticeably more out of JPEG than older defaults, so a well-encoded JPEG is still respectable.

What about PNG and GIF?

• PNG: keep it for source files, or when you need lossless output and the destination doesn't accept WebP. For web delivery, WebP lossless or a high-quality lossy WebP/AVIF is usually much smaller.
• GIF: for the web, replace it. Animated WebP, or a short muted <video> (MP4/WebM), is typically a fraction of the size with better colors.

Quality settings that actually work

Quality numbers are not comparable across encoders. "Quality 80" in one tool is not "quality 80" in another, and the same number means different things for JPEG, WebP and AVIF. That said, these are reasonable starting points:

• JPEG: around 75–82 is a sweet spot for most photos.
• WebP: around 75–82 for photos; try lossless for screenshots, logos and flat graphics.
• AVIF: you can often go lower than with JPEG/WebP (many people land somewhere in the 50–70 range, depending on the encoder's scale) and still look clean. Compare visually.

The method that matters more than the number: open the original and the compressed version side by side at 100% zoom, then lower quality until you can see a difference, and step back up a notch. Do this for a few representative images (a photo, a screenshot, an illustration) and use those settings as your defaults.

Resize before you compress

The single biggest mistake isn't the format, it's dimensions. A 4000px-wide photo straight off a phone, displayed in a 800px-wide column, wastes most of its bytes no matter how good the codec is.

Rules of thumb:

• Find the largest size the image is actually displayed at (check your layout's max content width).
• Export at that width, plus a 2x version for high-density screens if the image is important.
• For full-width hero images, a few widths (for example 640, 1280 and 1920px) cover most devices.

Serving modern formats with <picture> and srcset

Combine format fallback and responsive sizes so each browser picks the best file it supports:

<picture>
  <source
    type="image/avif"
    srcset="hero-640.avif 640w, hero-1280.avif 1280w, hero-1920.avif 1920w"
    sizes="(max-width: 800px) 100vw, 800px">
  <source
    type="image/webp"
    srcset="hero-640.webp 640w, hero-1280.webp 1280w, hero-1920.webp 1920w"
    sizes="(max-width: 800px) 100vw, 800px">
  <img
    src="hero-1280.jpg"
    srcset="hero-640.jpg 640w, hero-1280.jpg 1280w, hero-1920.jpg 1920w"
    sizes="(max-width: 800px) 100vw, 800px"
    width="1280" height="720"
    alt="Describe the image here"
    fetchpriority="high">
</picture>

A few details worth keeping:

• Order matters: the browser uses the first <source> it supports, so put AVIF first, then WebP, with JPEG in the <img>.
• Always set width and height to prevent layout shift.
• Use loading="lazy" for images below the fold, and don't lazy-load your LCP/hero image; give it fetchpriority="high" instead.
• If your browser support targets are all modern, you can reasonably skip the JPEG fallback and serve WebP as the <img> source. Many sites keep it anyway for robustness.

A practical workflow for converting your site's images

Here's a simple process that works for a blog, a portfolio or a small marketing site:

1. Keep originals. Store high-quality masters (JPEG at high quality, PNG, or RAW) somewhere separate. Never re-compress an already compressed file repeatedly; quality degrades each time.
2. Resize to the widths you actually need.
3. Convert photos to AVIF and WebP (and JPEG if you need the fallback). Convert logos, icons and screenshots to WebP (lossless or high-quality lossy), or keep SVG for vector artwork.
4. Compare visually at 100% on a few samples and tune quality.
5. Batch the rest with the settings you settled on.
6. Wire up <picture>/srcset, then check the result with Lighthouse or your browser's network panel.

Option 1: Convert in the browser, with no uploads

Many online converters upload your images to a server, process them there, and send them back. That's slower for big batches, and it's a real concern for client work, unreleased product shots, or anything under NDA.

Browser-based tools that run on WebAssembly avoid that entirely: the encoder runs on your own machine, inside the browser tab, and files never leave your device.

Zippic is one such tool. It's free, needs no sign-up, and compresses and converts JPG, PNG, WebP, AVIF, GIF, BMP and even RAW files locally via WebAssembly. It handles batch processing, which is handy for step 5 above: drop in a folder's worth of images, pick the output format and quality, and download the results. The interface is available in 11 languages, which helps if you work with international teams.

Squoosh (from the Chrome team) is another excellent in-browser option, and it's great for step 4: its side-by-side slider makes it easy to compare codecs and quality settings on a single image. It's designed around one image at a time, so for larger batches a batch-oriented tool or the command line is more convenient.

Option 2: The command line and build pipelines

If you're automating, the standard encoders are free and scriptable:

# WebP at quality 80
cwebp -q 80 input.jpg -o output.webp

# AVIF (libavif); check `avifenc --help` for the quality/speed flags in your version
avifenc input.jpg output.avif

Libraries such as sharp (Node.js) or libvips, and image plugins for frameworks and static site generators, can generate all your sizes and formats at build time. Many CDNs and image services can also convert on the fly based on the browser's Accept header.

The command line is ideal for repeatable pipelines. A browser tool like Zippic is often faster for one-off jobs: a batch of blog images, a client's photo set, or converting a few RAW or HEIC files without installing anything.

The short answer

• Default to WebP for most web images; it's fast, widely supported and handles transparency and animation.
• Use AVIF for large photos and hero images where every kilobyte counts, with WebP or JPEG as a fallback.
• Keep JPEG for email, external platforms and as the universal fallback.
• Resize first, start around quality 75–82 for JPEG/WebP, and trust your eyes over the numbers.

Pick a few representative images from your site today, convert them, and compare. You'll likely find meaningful savings, and your visitors on slow mobile connections will notice.