How to compress images without visible quality loss: JPG quality, WebP and resizing

The photo is 4032×3024 pixels and several megabytes; the form accepts 200 KB. Or the page-speed report says images are most of what your visitors download. Either way, you need a much smaller file that nobody can tell apart from the original. That is usually achievable, because most of the bytes in a photo are not fine detail at all — they are pixels no screen will ever show, quality no eye can see and metadata no viewer needs. This guide walks through where the bytes go, in which order to remove them, the exact controls in the site’s compress, resize and format converters, and a recipe table for web, email, forms and print.

Where the bytes actually go

Three things decide the size of a photo, and they are not equal. In order: how many pixels it has, how hard the encoder was allowed to squeeze them (the quality setting), and which format did the squeezing. Pixel count dominates because it multiplies everything else. A 4000×3000 camera frame holds 12,000,000 pixels. A laptop screen is typically 1440–1920 pixels wide; an article column is 700–900. Resizing that frame to 1600×1200 leaves 1,920,000 pixels — 6.25 times fewer — before the quality slider has moved at all. At a matching quality the file shrinks by roughly the same factor, because JPEG and WebP cost a fairly steady number of bits per pixel for a given kind of content.

Quality is the second lever, and it is a curve, steep at one end. Format is the third: switching a photo from JPG to WebP at the same look saves a quarter to a third; switching a photo from PNG to JPG saves several times that, because PNG cannot throw anything away. A useful rule of thumb from our own size-cap code: at middling quality a lossy encoder needs about one byte per 12 pixels, so a 200 KB budget can honestly carry about 2.4 megapixels — roughly 1800×1350 — and no quality slider will make 12 megapixels fit into it without visible damage.

The JPG quality scale is not linear

JPEG’s 1–100 “quality” is not a percentage of anything you can see. It scales a table of quantisation steps applied to each 8×8 block of pixels after a frequency transform. Because most encoders inherit the scale from libjpeg, the same number means about the same thing in GIMP, ImageMagick and every browser. What the numbers do in practice:

• 90–100: the quantisation steps approach 1, so the encoder keeps noise, sensor grain and rounding error as faithfully as real detail. Going from 85 to 100 commonly doubles the file while changing nothing you can point to.
• 75–85: visually transparent for photographs at normal viewing size. This is the range to use.
• 60–75: fine for thumbnails and busy textures; smooth gradients (skies, skin) start to band.
• below 60: the 8×8 grid becomes visible as blocks in flat areas and as halos (“ringing”) around sharp edges and text.

There is a second setting most tools never show: chroma subsampling. Human eyes resolve brightness far more finely than colour, so JPEG encoders normally store colour at half resolution in both directions (written 4:2:0 — one colour sample per four pixels) and full-resolution brightness. For photos this is free compression. For a screenshot with red text on white, it smears the edges of every letter, and no quality number fixes it. Browser encoders — the ones this site uses — expose a single quality argument (canvas.toBlob(cb, 'image/jpeg', 0.8)) and no subsampling or progressive option, so the rule is simpler: text and line art go to PNG or lossless WebP, never JPG.

Lossless, lossy, and which format for what

PNG is lossless: it filters each row and DEFLATE-compresses the result, so every pixel comes back bit-exact. That is what makes it ideal for screenshots, diagrams and logos, and terrible for photographs, where sensor noise defeats DEFLATE and the file lands at three to ten times the JPG. “Optimising” a PNG means reducing colours to an 8-bit palette (256 entries) where the image allows it, and spending more CPU on the same DEFLATE stream (the Zopfli approach); it never changes the pixels and it cannot rescue a photo. WebP has both modes in one container: lossy WebP encodes photos smaller than JPEG at equal quality — Google’s own comparison puts it at 25–34% smaller at the same SSIM score — and lossless WebP is typically smaller than PNG, both with transparency. AVIF goes further still, but no browser can encode it from a canvas, so tools on this site read AVIF and write JPG, PNG or WebP.

Resize first, then compress: the controls on this site

Every image tool here opens the picture in the same in-browser editor and ends at the same “Save as” dialog, so the workflow is: fix the pixel count, then set the encoding. The resize toolopens straight on the Resize tab with “Width in pixels” and “Height in pixels” fields and a ratio lock, on by default. It keeps the source format for JPG, PNG and WebP inputs and saves everything else as JPG. Inputs cover jpg, png, webp, heic, avif, tiff, psd, bmp, gif, svg and more; formats the browser cannot show are decoded by a WebAssembly ImageMagick first, HEIC by libheif. One limit to know: the editor pre-shrinks anything with a side longer than 4096 px and tells you so — Large image resized to 4096 × 3072px so it can be edited and saved on this device. — because it keeps several full-size copies in memory. For print masters above that, keep the camera original rather than passing it through the editor.

The “Save as” dialog has a Format menu (png, jpeg, jpg, webp), a Quality slider from 1 to 100 that appears for the lossy formats and defaults to 92, a Resize row, and two fields we added:

• Max file size (KB, optional) — the control for forms with a byte limit. The tool first shrinks the pixel count to what the budget can hold (about 12 pixels per byte), then binary-searches the quality between 5 and 97 over seven rounds for the highest value that still fits, and if even quality 5 is too big it scales the dimensions down in 25% steps and searches again. The result is guaranteed at or under the cap. Because a PNG has no quality knob, choosing PNG with a cap produces a JPG; choose WebP and the cap is met in WebP.
• Compress image (smaller file, quality adjusts automatically) — one tick, no numbers: encode at quality 72 and pull any side longer than 2560 px down to 2560. It honours the format you chose, so a PNG stays a PNG and only gets the downscale. On the compress tool this box is pre-ticked and the format defaults to JPG; on the other tools it is off.

The WebP converter and JPG converteruse the same editor for a single file, and add a batch path when you drop several: “Convert all to WebP (ZIP)” (or JPG) encodes each at quality 92 with no editing and downloads converted-webp.zip, with its own “Max size per image (KB, optional)” field and “Compress images” tick that apply the same two rules to every file. “Edit each image” instead opens the editor for each in turn and zips the saves as edited-images.zip. The batch path has no 4096 px pre-shrink. Converting to JPG flattens transparency onto white, and nothing is uploaded, so a passport scan or a medical image is compressed without leaving the device.

Recipes: dimensions, format and quality by destination

Long edge is the dimension to think in — set it, lock the ratio and let the short edge follow. Quality numbers are ranges on purpose; test one image from your set at the low end and look at a sky or a face at 100% zoom.

Two notes on the cap rows. First, type a little under the stated limit: the tool counts 1 KB as 1024 bytes, so “200” produces up to 204,800 bytes, which a form counting in thousands will reject. Second, leave the cap blank for print — it is built to hit a byte target, not to protect detail — and use the slider.

Metadata: the bytes you did not take

A camera JPG carries an EXIF block in its APP1 segment: make, model, lens, exposure, GPS coordinates, timestamp, and usually a 160×120 preview thumbnail of theuncroppedframe. Manufacturer “MakerNotes” and an XMP block with edit history can push that past tens of kilobytes, and an embedded colour profile adds more. On a 3 MB file that is a rounding error; on a 150 KB web image it can be a fifth of the total. Every save on this site is a fresh encode from a canvas, so none of it is copied across: orientation is baked into the pixels, the output is untagged (which every viewer treats as sRGB), and the GPS and thumbnail are gone. If you want the metadata gone but the pixels untouched, the metadata guide covers stripping without re-encoding.

How to tell what is eating the bytes

Before touching a slider, measure. Three commands answer most cases on a Mac or Linux machine:

# dimensions and format from the header (macOS: sips; anywhere: file)
sips -g pixelWidth -g pixelHeight photo.jpg
file photo.jpg
#   JPEG image data, Exif standard ... 4032x3024

# ImageMagick: estimated quality and chroma subsampling of an existing JPG
identify -format '%wx%h q=%Q %[jpeg:sampling-factor]\n' photo.jpg
#   4032x3024 q=93 2x2,1x1,1x1   -> 2x2 is 4:2:0; 1x1 across the board is 4:4:4

# first bytes tell the real format regardless of extension
head -c 12 photo.jpg | xxd
#   ffd8 ff..            JPEG
#   8950 4e47 0d0a 1a0a  PNG
#   5249 4646 .... .... 5745 4250  RIFF....WEBP
#   .... .... 6674 7970 6865 6963  ....ftypheic (HEIC)

Then pick the case:

• Width over 2000 px and the target is a screen — resize. Nothing else matters until this is done.
• Estimated quality 92 or higher — re-encode at 80. Expect the file to roughly halve with no visible change.
• A photo saved as PNG (screenshot of a photo, export from a design tool) — convert to JPG or WebP; the saving is usually a multiple, not a percentage.
• Small dimensions but still large — metadata or an embedded profile; any re-encode drops it.
• The tool says Could not read this image. The file may be corrupted or in a format this browser cannot decode. — check the bytes above; a file called .jpg that starts with ftypheic is a renamed HEIC and should go through the HEIC route.

Common mistakes

• Re-saving a JPG again and again. Each save re-quantises the blocks, and the errors accumulate — the fourth generation of a quality-80 save looks worse than a single quality-60 save. Keep one original and make every delivery copy from it. The tools here never overwrite the input, so the original is safe by default.
• Upscaling. Typing 3000 into the width field of a 1200 px image invents nothing; the encoder then spends bytes describing the blur. Send what you have.
• PNG for photos, JPG for screenshots. They run opposite ways: a photo in PNG is several times too large, a screenshot in JPG has smeared text from 4:2:0 subsampling. Text and flat colour go lossless; noise and gradients go lossy.
• Choosing quality 100.It is not “lossless” — the 8×8 transform and 4:2:0 subsampling still happen — it is merely the largest possible lossy file.
• Reading file size as quality. A 100 KB image can be a crisp 800 px WebP at quality 80 or a blocky 4000 px JPG at quality 15. Judge the pixels at 100% zoom; the byte count only tells you whether it will upload.
• A cap the pixels cannot meet. Ask for 20 KB from a 12-megapixel photo and the size-cap search will get there, but by scaling the picture down in 25% steps until it fits. If the result is too small to read, crop to the part that matters or raise the cap. When no size can satisfy the cap, the save fails with Could not convert the edited image to JPG. Try saving as PNG or JPG instead.
• Transparency into JPG. A logo on a transparent background converted to JPG gets a white background here (other tools may use black). Keep PNG or WebP if the edge must stay transparent.
• WebP where a form named JPG. Validation usually checks the extension or the MIME type, not the bytes, and rejects .webp outright. Produce exactly the format the form names.