Image Tools

Image compression: what actually gets smaller

Lossy, lossless, PNG, JPEG, WebP, and AVIF explained for smaller images without ugly surprises.

ToolerasMay 9, 202624 min read5,212 words

The product page shipped on a Thursday afternoon, because of course it did. Thirty-seven images, most of them product shots, averaged about 580KB each. Nobody liked the network waterfall, but nobody wanted to delay the release either, so a developer did the thing every team eventually does: dragged the folder into an optimizer, accepted the defaults, and watched the total image weight drop.

The result looked fine in the terminal. The average image went from 580KB to about 480KB. Not great, but measurable. A ticket got closed. The deploy went out. Nobody opened the page on a mid-range phone. Nobody compared the before and after hero at full size. Nobody zoomed into the shadow under the main product, where the smooth gradient had turned into chunky rectangles.

Then a customer emailed.

The hero image looked blocky. Not "a designer noticed after staring at it for ten minutes" blocky. Just plain blocky. The product looked cheaper than it was. The page loaded a little faster and sold the product a little worse.

That's the gap between compression and compression that matches your use case.

Image compression isn't one knob. It's a set of tradeoffs: pixels, dimensions, color information, repeated patterns, metadata, decoder support, visual masking, CPU time, and how much damage you're willing to hide in places people won't notice. Sometimes the right answer is a smaller file in the same format. Sometimes it's a new format. Sometimes it's not format compression at all, it's resizing a 4000 pixel source image before you ever talk about WebP or AVIF.

This guide is for the developer, designer, or content creator who knows PNG, JPEG, WebP, and AVIF by name but hasn't had to think about what actually gets removed. We'll keep it practical, but we're going to name the machinery. If you understand what the encoder is allowed to throw away, you'll stop treating "optimize images" as a ritual and start treating it as an engineering decision.

What compression actually does

Compression makes a file smaller by representing the same image data, or a close enough version of it, with fewer bytes.

There are two broad families.

Lossless compression reconstructs the original data exactly. If you compress an image losslessly, decompress it, and compare the output pixel by pixel, the pixels match. The encoder is allowed to reorganize, predict, and pack the data, but it isn't allowed to change the final image. ZIP, PNG, FLAC, and Brotli are familiar examples in different domains. They look for repetition, structure, and predictability.

Lossy compression makes a smaller file by discarding information. The promise isn't "you'll get the same pixels back." The promise is "you probably won't care about the difference at the intended display size." JPEG, lossy WebP, and AVIF are in this family. They rely on human perception: we're less sensitive to some color changes than brightness changes, we don't inspect every high-frequency detail in a photo, and noise in a busy background can hide a lot of damage.

Both approaches are legitimate. Lossless isn't morally better. Lossy isn't automatically sloppy.

For photos, lossy usually wins because photographic images contain gradients, texture, sensor noise, blur, depth of field, and lots of detail that can be approximated. If you save a 3000 pixel food photo as lossless PNG, you may preserve every pixel and still punish every visitor with a huge file. That's not care. That's refusing to decide.

For UI assets, diagrams, screenshots, icons, charts, text, and code snippets, lossless often wins because the image depends on sharp boundaries. A one-pixel line, a letterform edge, or a crisp chart axis doesn't hide damage well. JPEG's block artifacts and chroma subsampling can smear exactly the thing the image exists to communicate.

Compression also isn't only a format question. An 800px display slot doesn't need a 4000px source image unless you're serving high-density variants. Removing 80 percent of the pixels by resizing usually saves more than changing from JPEG to WebP. The order matters: resize first, then encode from the highest-quality source you have.

A good image pipeline asks four questions:

What is the content: photo, screenshot, diagram, icon, animation, transparent asset?
What size will users actually see?
What quality loss is acceptable at that size?
Which browsers, apps, feeds, or CMS layers need to read the result?

The format comes after those answers.

PNG keeps pixels exact by making them predictable

PNG is lossless, but that doesn't mean it's simple. It doesn't just "zip the pixels." It prepares the pixels so the compressor sees patterns.

The original PNG specification was published as RFC 2083 in March 1997. That RFC is now historic, and the current W3C authority is the PNG Specification Third Edition, published as a W3C Recommendation on 24 June 2025. PNG's compression method depends on DEFLATE, the same general compression format specified in RFC 1951 in May 1996.

DEFLATE combines LZ77-style back references with Huffman coding. In plain English, it says: "I've seen this byte pattern before, so I'll point back to it instead of writing it again," then it gives shorter codes to values that appear more often. That's excellent for repeated or predictable data.

Raw image pixels aren't always friendly to DEFLATE. A photo scanline might look noisy even when the image looks smooth. PNG improves the odds with filters.

A PNG filter is a reversible prediction step applied before compression. Each scanline gets a filter type byte, then the filtered bytes. The decoder reverses the filter after decompression, so the final pixels are unchanged. The W3C PNG spec defines five filter types for filter method 0:

None stores the bytes as they are.
Sub predicts each byte from the byte to its left.
Up predicts each byte from the byte above it.
Average predicts from the average of left and above.
Paeth predicts from left, above, and upper-left, then chooses the neighbor closest to a simple gradient estimate.

Imagine a flat blue toolbar. Pixel after pixel has nearly the same RGB values. A Sub filter turns "blue, blue, blue, blue" into "blue, zero difference, zero difference, zero difference." DEFLATE loves long runs of small repeated values. A photo doesn't collapse as neatly, but filters can still reduce local variation.

PNG also has palette modes. PNG-24 usually means full 24-bit truecolor: 8 bits each for red, green, and blue. PNG-8 means indexed color, where each pixel stores a small palette index, often 8 bits or less, instead of full RGB values. If an icon uses 34 colors, storing one byte per pixel plus a palette is much smaller than storing three or four bytes per pixel. That's why a PNG-8 logo, badge, chart, or flat illustration can be tiny without changing a visible pixel.

This is also why PNG can beat JPEG for simple content. JPEG has fixed overhead and works in blocks. It has to encode frequency data, quantization tables, and entropy-coded coefficients. For a simple icon with hard edges and a small palette, PNG can say "same color again, same color again" with ruthless efficiency. A same-content JPEG may add ringing around edges, lose transparency, and still end up larger.

The rule isn't "PNG is bigger." The rule is "PNG is lossless and loves predictable pixels." Icons, diagrams, UI screenshots, line art, small transparent assets, and images with limited palettes are predictable. Photographs usually aren't.

JPEG gets small by changing the question

JPEG doesn't try to preserve pixels. It tries to preserve the visual impression of a photo.

The core JPEG standard is ITU-T T.81, approved on 18 September 1992, with the identical ISO/IEC 10918-1 standard following later. The ITU page for T.81 is the specification entry. The W3C's JPEG JFIF overview is also useful because it explains the web-facing file format people usually mean by "a JPEG."

JPEG's classic lossy path starts by converting RGB into a luma and chroma representation, often YCbCr. Luma is brightness detail. Chroma is color difference detail. Human vision is more sensitive to brightness structure than to fine color detail, so JPEG can spend more bits on luma and fewer on chroma.

Then JPEG divides the image into 8 by 8 pixel blocks and applies the discrete cosine transform, or DCT. The DCT turns pixel values into frequency coefficients. The top-left coefficient represents the average value for the block. Other coefficients represent increasingly fine horizontal, vertical, and diagonal changes.

This is where "what gets smaller" becomes literal. JPEG isn't mainly storing pixels anymore. It's storing a recipe of frequencies per block.

The lossy part is quantization. The encoder divides DCT coefficients by values in quantization tables, rounds the results, and throws away precision. High-frequency coefficients often become zero, especially at lower quality settings. Long runs of zeroes compress well. The decoder reverses the math as best it can, but the original values are gone.

That means the quality slider is not a percentage of retained image quality. Quality 80 doesn't mean "keep 80 percent of the pixels." It's an encoder-specific control that maps to quantization tables, chroma behavior, scan decisions, and sometimes psychovisual tuning. A JPEG at q82 from one encoder can be larger or uglier than q76 from another. The quality number is a local dial, not a universal unit.

Chroma subsampling is another big lever. The notation looks cryptic until you see what it's saying:

4:4:4 keeps full chroma resolution. Color detail is sampled as densely as brightness detail.
4:2:2 halves chroma horizontally.
4:2:0 halves chroma horizontally and vertically.

For many photos, 4:2:0 is a good trade. Skin, skies, fabric, and background texture often survive it well. For screenshots, code, red text on a dark background, or thin colored lines, 4:2:0 can look awful because color edges bleed. If your diagram has sharp red labels, JPEG may damage the exact data you're trying to show.

Baseline JPEG and progressive JPEG are about how data is ordered. Baseline JPEG paints roughly top to bottom as bytes arrive. Progressive JPEG sends the image in multiple scans: first a coarse whole-image view, then refinement. Progressive files are often slightly smaller and can feel faster on slow connections because users see the full frame early, even if blurry at first. The W3C JPEG page notes progressive JPEG is part of the original JPEG specification and is widely supported now.

MozJPEG exists because JPEG's format is old but encoders can still make smarter choices inside it. Mozilla introduced the mozjpeg project in March 2014 and announced mozjpeg 2.0 in July 2014. It improved file size while staying compatible with normal JPEG decoders. Its tricks include trellis quantization and better progressive scan optimization. The current GitHub project page lists features such as progressive encoding with jpegrescan optimization and trellis quantization, and the releases page shows v4.1.1 as the latest official mozjpeg release, dated 15 August 2022. I can't verify a mozjpeg "2.1 release Aug 2023" claim from the official release page, so don't pin production guidance to that date.

JPEG XL is worth knowing about, but it's not the default web answer in 2026. It has real technical appeal, including efficient recompression of existing JPEGs, but browser deployment is still uneven. Safari supports it, Chrome 145 added JPEG XL decoding behind the enable-jxl-image-format flag according to Chrome for Developers release notes, and Firefox still isn't a default yes for public delivery. Mention it in architecture notes. Don't make it your only product-image format unless your audience and fallback path are tightly controlled.

JPEG's position is simple: it's old, everywhere, and still useful. For photographs where compatibility matters, a well-encoded JPEG is not embarrassing. A bad JPEG pipeline is.

WebP is two formats wearing one extension

Google announced WebP on 30 September 2010 in the Chromium Blog post "WebP, a new image format for the Web". It began as a way to make photographic web images smaller by using VP8 intra-frame ideas in a still-image container.

Modern WebP has two main compression modes.

Lossy WebP is based on VP8 intra-frame coding. Like video keyframes, it predicts blocks from neighboring pixels, stores residuals, transforms and quantizes them, then entropy-codes the result. This is the mode most people mean when they say "convert JPEGs to WebP."

Lossless WebP, sometimes called VP8L, is a different path. It stores ARGB pixels exactly using predictors, transforms, LZ77-style ideas, prefix coding, and a color cache. It's more like a PNG competitor than a JPEG competitor.

The IETF RFC number to cite is not RFC 9459. RFC 9459 is about COSE encryption modes. WebP's IETF document is RFC 9649, WebP Image Format, published in November 2024. It defines the RIFF-based WebP container, lossy VP8-based WebP, and lossless WebP.

Google's WebP documentation says lossy WebP images are 25 to 34 percent smaller than comparable JPEG images at equivalent SSIM quality, and lossless WebP images are 26 percent smaller than PNGs in their tests. Treat those as useful directional numbers, not a promise for every asset. A noisy photo, a flat icon, and a screenshot of code won't move the same way.

Browser support used to be the argument against WebP. In 2026, for normal web pages, that argument is mostly gone. MDN's image format guide lists WebP support across major browsers and notes Safari needs Safari 14 or later on macOS Big Sur or newer. Apple's Safari 14 release notes date that release to 16 September 2020.

WebP is a good default for many sites because it's widely supported, faster to encode than AVIF, and good enough to produce real savings. It's not magic. Lossless WebP can still be larger than PNG for some indexed-palette images. Lossy WebP can still smear text if you push it too hard. But for product photos, editorial images, thumbnails, and social-card images, WebP at sane quality settings is usually a strong upgrade over legacy JPEG.

AVIF gets smaller by borrowing from modern video

AVIF is the AV1 Image File Format. It's based on AV1, the royalty-free video codec whose 1.0 specification was publicly released by AOMedia on 28 March 2018. The AVIF v1.0.0 specification is dated 19 February 2019.

AVIF stores AV1-coded image data in a HEIF-family container and follows constraints inspired by MIAF, the Multi-Image Application Format. The original MIAF edition was ISO/IEC 23000-22:2019, published in June 2019 and now superseded by ISO/IEC 23000-22:2025.

The practical meaning is that AVIF gets access to much newer coding tools than JPEG: larger and more flexible block structures, stronger prediction modes, better transforms, better entropy coding, higher bit depths, HDR and wide-gamut support, alpha, and animation. AOMedia's AVIF page says AVIF can provide over 50 percent savings compared with JPEG and over 30 percent compared with WebP. In day-to-day web work, a more cautious expectation is usually 30 to 50 percent smaller than JPEG and 20 to 30 percent smaller than WebP at similar visual quality, depending heavily on content and settings.

The tradeoff is encode cost. AVIF can be slow, especially on CPU, especially with high-effort settings, and especially if you're making many sizes for many images. Decoding support is much better than it was, but encoding still takes patience and good defaults.

Browser support is now good enough for production with fallbacks, but the exact version history matters. Chrome landed AVIF support in M85, noted in Google's AVIF encoding article. MDN's image guide lists AVIF browser compatibility as Chrome 85, Edge 121, Opera 71, Firefox 93, and Safari 16.1. WebKit's Safari 16.0 post says iOS 16 Safari included still-image AVIF support on 12 September 2022, with macOS Ventura and iPadOS following in October. The common "Firefox 86+" claim is messy: Mozilla's Bugzilla history shows the Firefox 86 work was backed out before broad reliable support, while MDN lists Firefox 93 for still images. If you're writing a compatibility table, use Firefox 93 unless you have a very specific reason to discuss the earlier attempt.

AVIF is ready for production when you serve it through <picture> or content negotiation with WebP or JPEG fallbacks. It's not ready if your workflow means "replace every image with AVIF and hope every consumer accepts it." Email clients, social platforms, design tools, CMS plugins, and marketplace feeds often trail browsers.

Use AVIF where byte savings are worth the encode time: large hero photos, gallery images, mobile-heavy pages, high-traffic assets, and cases where better quality at lower size improves LCP. Use WebP when you need faster builds, simpler tooling, or broader non-browser compatibility.

Six ways compression goes wrong in real projects

1. Using PNG for photos

What people try: They export product photography as PNG because PNG is "higher quality" or because they don't want artifacts.

What to do instead: Use lossy WebP, AVIF, or a high-quality JPEG. Start from the original source, resize to needed dimensions, and compare at the actual display size. PNG preserves every pixel, including sensor noise and tiny texture variations users don't need. For photos, that exactness is usually wasted bandwidth.

Keep PNG for the logo overlay, not the lifestyle shot behind it.

2. Using JPEG for diagrams and screenshots

What people try: They convert screenshots, code samples, charts, and UI diagrams to JPEG because JPEG usually means small.

What to do instead: Use PNG, WebP lossless, or SVG when the image is truly vector-like. If the screenshot is photographic, such as a game scene or video frame, lossy may be fine. If it contains text, code, UI controls, table borders, or chart labels, JPEG will often blur edges and add halos. The file may be smaller, but the content becomes less readable.

For screenshots of code, a crisp 220KB PNG is better than a 90KB JPEG that makes every l and 1 look suspicious.

3. Uploading 4000 by 3000 images for an 800px slot

What people try: They export from a camera or design tool, compress the image, and ship the full dimensions because CSS will display it at 800px anyway.

What to do instead: Resize first. Dimensional compression comes before format compression. If the largest rendered width is 800 CSS pixels and you want to cover 2x displays, generate around 1600px wide, not 4000px. Keep the original in your asset system, but don't send it to every visitor.

This is the fastest way to make images smaller because pixels are expensive. A 4000 by 3000 image has 12 million pixels. An 800 by 600 image has 480,000. No encoder setting competes with not encoding 11.5 million extra pixels.

4. Running images through multiple encoders in sequence

What people try: They export a JPEG from a design tool, upload it to a CMS that recompresses it, download it, run it through another optimizer, then maybe have a CDN transcode it again.

What to do instead: Keep a high-quality source and encode delivery variants from that source. Lossy generation loss compounds. Every lossy encode guesses what can be thrown away based on the image it receives. If that image already has block artifacts, mosquito noise, or smeared color, the next encoder may preserve the damage while discarding more real detail.

Never use a social-media-downloaded JPEG as your master. That's a delivery artifact, not a source asset.

5. Using `<img>` without `srcset` or `<picture>`

What people try: They make one optimized image and put it in <img src="hero.webp">.

What to do instead: Serve size variants with srcset and format variants with <picture> when needed. A desktop monitor, a small phone, and a high-density tablet shouldn't all receive the same image. Modern HTML lets the browser choose from candidates:

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w">
  <img
    src="hero-800.jpg"
    srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
    sizes="(min-width: 900px) 800px, 100vw"
    alt="Product on a walnut desk">
</picture>

The compressor makes files smaller. Responsive images stop you from sending the wrong file.

6. Compressing photos below JPEG quality 60

What people try: They keep lowering JPEG quality until the number looks impressive in a dashboard.

What to do instead: Treat q60 as a caution line, not a dare. Some photos survive lower values. Many don't. At low JPEG quality, you start seeing block boundaries, ringing around edges, posterized gradients, and muddy texture. For thumbnails, maybe that's acceptable. For product heroes, portraits, food, artwork, and anything meant to build trust, it's usually too far.

If q60 JPEG is still too large, try resizing, WebP, AVIF, chroma settings, metadata removal, or a different crop before you crush the image.

The format-picking flowchart

Use this as a starting point, then check real output.

Is it a vector-like UI asset, icon, logo, or simple illustration?
  -> Use SVG first.
  -> If raster is required, use PNG or WebP lossless.

Is it a screenshot of text, code, UI, charts, or diagrams?
  -> Use PNG or WebP lossless.
  -> Try PNG-8 if the palette is small.

Is it a photograph for the web?
  -> Use AVIF around q60 when encode time and fallbacks are acceptable.
  -> Use WebP around q80 as the practical default.
  -> Keep JPEG fallback when needed.

Does it need transparency?
  -> For simple UI, use SVG first.
  -> For raster UI, use PNG or WebP lossless.
  -> For photographic transparency, try WebP or AVIF with alpha.

Is it animated?
  -> Use animated WebP or AVIF in 2026.
  -> Don't use GIF unless you're targeting a platform that only accepts GIF.

Is it for email, marketplace feeds, older CMS plugins, or social previews?
  -> Verify accepted formats.
  -> JPEG and PNG are still the safest interchange choices.

The defaults I'd try first:

Photo for web: WebP q80 or AVIF q60.
Screenshot of code or text: PNG or WebP lossless.
Diagram: SVG if possible, otherwise PNG or WebP lossless.
Animated: WebP or AVIF, not GIF for modern web delivery.
Transparent UI asset: SVG first, PNG second, WebP lossless when it tests smaller.

Encoder recommendations that won't waste your week

Use specialized encoders when the format matters, and use higher-level tools when the pipeline matters.

libjpeg-turbo is still the default JPEG library in many systems because it's fast. It uses SIMD paths for common CPU architectures and is an ISO/IEC and ITU-T reference implementation of JPEG. Use it when you need speed, decoding, broad compatibility, or normal JPEG output in server workflows.

MozJPEG is for squeezing more out of JPEG while keeping JPEG compatibility. It costs more CPU at encode time but can produce smaller files at the same visual target through trellis quantization and progressive scan optimization. Use it for web delivery images where JPEG fallback quality matters.

libwebp is Google's reference WebP implementation. Its cwebp tool supports lossy, lossless, quality settings, presets, resize, crop, alpha options, metadata copying, and multi-threading. If you want to understand WebP output rather than trust a wrapper, start with cwebp.

libavif is the practical AVIF library to know. It provides avifenc and avifdec, supports AV1 YUV formats and bit depths with alpha, and can use codec backends such as AOM. Use libavif when you want AVIF control and predictable command-line behavior.

For AV1 encoding backends, AOM's reference encoder is a quality baseline, while SVT-AV1 is aimed at faster CPU encoding and scalable performance. For still AVIF, the right choice depends on your toolchain, speed needs, and whether the wrapper you're using exposes the backend cleanly.

Squoosh.app is great for comparing one image by eye. Its GitHub repository describes it as an image compression web app that runs codecs in the browser and says images aren't sent to a server. Use it when you need to learn what settings do before encoding thousands of files.

Sharp is the Node.js workhorse for resizing and converting images in application code. It wraps libvips, and the npm page describes the common use case as converting large images into smaller web-friendly JPEG, PNG, WebP, GIF, and AVIF images. Use Sharp when you need a build step, upload pipeline, or server-side image service in JavaScript.

ImageMagick is the broad utility knife. It reads and writes many formats, can resize, crop, convert, inspect metadata, and script batch operations. It's often slower than focused libraries like libvips or single-format encoders, but it's invaluable for odd formats and one-off transformations.

One caution: don't hide encoder settings forever behind "quality: 80." Store enough configuration that future you can answer what happened: target width, output format, quality, chroma subsampling when available, metadata policy, and source file lineage.

What the Tooleras image tools do

The image compressor at tooleras.com/tools/image-compressor is designed for quick, private browser-side compression. It runs client-side, using browser canvas plus a compression worker. That matters because the practical workflow is simple: you bring an image, the browser does the work, and the file doesn't need to be uploaded to a server just to reduce its size.

That also defines the boundaries.

The image compressor is good for everyday reductions: making a JPEG or PNG lighter before a blog upload, shrinking a product image for a CMS, or creating a smaller asset when you don't need a full build pipeline. It's a convenience tool for people who need a smaller file now and don't want to install command-line encoders.

It isn't a replacement for a full image CDN, a tuned AVIF farm, or a CI pipeline that generates every srcset width. Browser canvas has format and metadata limits. It won't give you every low-level encoder flag that cwebp, avifenc, MozJPEG, or Sharp can expose. It also won't decide your art direction, crop strategy, alt text, or responsive markup.

Tooleras also has an image resizer and an image cropper. Use the resizer when the problem is dimensions: the image is 4000px wide and only needs to render at 1200px. Use the cropper when the problem is composition: the subject is too small, the social preview needs a different aspect ratio, or the hero should focus on the product instead of the empty wall around it. Use the compressor when the dimensions and crop are already right and the remaining problem is file weight.

The honest order is crop, resize, then compress. If you compress first and crop later, you'll often re-encode and lose quality twice.

FAQ

Which format should I use in 2026?

For photos on public websites, start with AVIF plus WebP or JPEG fallback if you have the pipeline for it. If you want one practical modern format, use WebP. For screenshots, diagrams, and UI assets, use PNG, WebP lossless, or SVG. For interchange with unknown systems, JPEG and PNG still win.

Why does my JPEG look worse after I optimized it?

Because JPEG optimization may be lossy recompression. If your source was already a JPEG, the optimizer may decode damaged pixels, quantize them again, and add a new layer of artifacts. Always encode delivery files from the cleanest source available, and compare before and after at the size users see.

Is AVIF ready for production?

Yes, for web delivery with fallback. Chrome, Safari, Firefox, and other major browsers now support AVIF well enough for normal sites, though exact versions vary. Use <picture> or server negotiation. Don't assume every CMS, email client, marketplace, or social platform accepts AVIF uploads.

What about JPEG XL?

Watch it, but don't depend on it as your only web format yet. JPEG XL has strong technical arguments, and support is improving in some browsers and tools. It still isn't a default universal target like JPEG, PNG, WebP, or increasingly AVIF. In 2026, it's a format to track, not the first format to ship without fallback.

How small is too small?

Too small is when the image stops doing its job. A hero image that makes the product look cheap is too small. A screenshot where code becomes hard to read is too small. A thumbnail can tolerate much more damage than a portfolio image. Decide by content and context, not just kilobytes.

Is lossless always higher quality?

It preserves pixels exactly, but that doesn't make it the better delivery choice. A lossless PNG photo can be visually identical to the source and still be a bad web asset because it's huge. Quality includes user experience: load time, battery, data cost, and whether the visible result is good enough.

Why did PNG beat JPEG for my icon?

Because the icon is simple. PNG can use a palette, filters, and DEFLATE to describe repeated flat colors efficiently. JPEG has block-based overhead and introduces artifacts around sharp edges. Simple graphics are exactly where PNG or SVG tends to win.

Should I remove metadata?

Usually yes for web delivery, especially GPS data, camera serials, and editing history. Keep ICC color profiles when color accuracy matters and your pipeline would otherwise shift color. Don't strip metadata blindly from archival masters. Strip it from exported delivery variants.

Does quality 80 mean 80 percent quality?

No. JPEG, WebP, and AVIF quality numbers are encoder controls, not universal percentages. They map to internal quantization and rate decisions. Compare outputs visually and by file size. Don't assume q80 in one encoder equals q80 in another.

Can I compress an image more without changing the format?

Often, yes. Resize it. Crop irrelevant pixels. Remove metadata. Use a better encoder. Adjust chroma subsampling. Try progressive JPEG. For PNG, try palette reduction if the image has limited colors. Format conversion is one move, not the only move.

Should I use GIF for animation?

Not for modern web delivery if you can avoid it. GIF is large, limited to 256 colors per frame, and inefficient for most animations. Animated WebP and AVIF are better web targets in 2026, with video formats also useful when the content is really a short clip.

What's the safest upload format for a CMS?

JPEG for photos and PNG for graphics. Then let a controlled pipeline generate WebP or AVIF delivery variants. If the CMS itself accepts WebP or AVIF, test the whole path: upload, transformation, CDN, cache, browser, social preview, and backup export.

Sources checked

Small images aren't the goal. Images that carry the right visual information at the smallest honest cost are the goal. That difference is the whole job. Compress photos like photos, screenshots like screenshots, icons like icons, and source files like things you'll need again. The bytes are real, but so is the trust your image is supposed to earn.

image compressionavifwebpjpegpngresponsive imagesmozjpeglibavif

Practice with free tools

200+ free developer tools that run in your browser.

Browse all tools →