Format Is the Decision That Comes Before Compression

In the previous lesson we established that images are the heaviest resource on most pages, that sizing correctly matters more than compression alone, and that image optimization covers six distinct problems. This lesson focuses on the first one you need to solve: which format should this image be in?

Format choice sits upstream of everything else. You can compress a JPEG down to a reasonable size, but if it should have been a WebP or an SVG in the first place, you have already accepted a penalty that no quality slider can recover. Getting this decision right before opening any tool is what separates an efficient image pipeline from one that compresses the wrong thing efficiently.

Two Fundamentally Different Kinds of Images

The first question to ask about any image is not “how compressed should it be?” It is: what kind of data is this image representing? The answer determines whether you should be working with a vector format or a raster format and these two are fundamentally different things.

Vector Images (SVG)

A vector image is a set of mathematical instructions: draw a circle here, fill this path with this colour, scale this shape to fit its container. SVG is the dominant vector format on the web, and it is worth really sitting with what that means: an SVG file is XML code. Not an image in the traditional sense, but a text document that describes how to draw an image.

Because SVG is text, it compresses as effectively as any JavaScript or HTML file. It can be inlined directly into your markup. And because it is mathematical rather than pixel-based, it scales to any size without any change to the underlying data. A logo at 20px and the same logo at 2000px use the exact same file, with the exact same file size.

One important step when working with SVGs exported from tools like Figma, Illustrator, or Affinity Designer is to run them through SVGO or SVGOMG, which is powered by SVGO.

Design tools embed significant amounts of editor metadata: layer names, unused definitions, redundant path data from bezier handles that cancel each other out. SVGO or SVGOMG strips all of that out. It is common to see file sizes drop by 40 to 60 percent with no visible change to the rendered output whatsoever.

SVG is the right choice for

Logos, icons, illustrations, charts, diagrams etc. Generally, anything whose content is defined by shapes, paths, and fills. If you are serving a raster PNG of your company logo, you are incurring a real cost that SVG would eliminate entirely.

There can be some exceptions, such as state flags with complex shapes that should be served as raster images icons, but in general SVG is the right choice for anything that isn’t a photograph or photorealistic texture.

That’s all about SVG and vector formats as this series will be focusing on raster formats which are the most common and the most frequently mishandled.

Raster Images (JPEG, PNG, WebP, AVIF)

Raster formats work entirely differently. A raster image is a fixed grid of pixels, and each pixel stores colour information. A 2000 by 1000 pixel photograph is always 2000 by 1000 pixels. If you scale it up, the browser invents the extra pixels through interpolation, which degrades quality. If you scale it down, you are downloading far more pixels than the screen will ever display.

This fixed-resolution nature is what makes raster images simultaneously the most common format on the web and the most frequently mishandled one. Photography, product imagery, and anything with complex colour gradients or photorealistic texture belongs in a raster format. The question is: which raster format?

That is where the real engineering decision begins.

The Format Duel: WebP, AVIF, and When to Pick Which

JPEG has been the default format for photographic web content since 1992. It remains ubiquitous because every browser, every OS, and every image viewer on the planet supports it. That universal support has kept it alive long past the point where better alternatives exist. In 2026, JPEG should be your last-resort fallback, not your starting point.

WebP: The Safe Default

WebP was developed by Google and released in 2010 as a direct replacement for both JPEG and PNG. It supports lossy and lossless compression, it supports transparency (which JPEG does not), and it produces files roughly 25 to 30 percent smaller than JPEG at equivalent visual quality. Browser support has sat at approximately 97 percent for years and can be treated as universal.

If you need a single format that works everywhere, imposes no meaningful encoding cost, and is unambiguously better than JPEG in every dimension, WebP is that format. It is the safe, sensible default for the overwhelming majority of web images.

AVIF: The Heavyweight

AVIF is derived from the AV1 video codec, and it represents a generational leap in compression efficiency. At equivalent quality, AVIF files are typically 40 to 50 percent smaller than JPEG and 20 to 30 percent smaller than WebP. For photographs with complex gradients, subtle skin tones, or heavily textured surfaces, AVIF’s quality-to-size ratio is often visibly better because it avoids the colour banding artifacts that occasionally appear in WebP at lower quality settings.

The trade-off is encoding speed. Generating an AVIF file is CPU-intensive in a way that WebP simply is not. Encoding a large JPEG into AVIF can take seconds of CPU time. This is precisely why the @jsquash library (which this entire series is built on) offloads AVIF encoding into a Web Worker running WebAssembly rather than blocking the browser’s main thread.

Browser support for AVIF sits at approximately 93 percent as of early 2026 and continues to grow. The standard practice is to offer AVIF as the primary format with WebP as the fallback, using the HTML <picture> element to let the browser select the best format it can handle.

JPEG XL: Watch, But Wait

JPEG XL (JXL) is worth a brief mention as an emerging format with impressive theoretical properties: near-lossless compression at tiny file sizes, support for very high dynamic range imagery, and a progressive decoding model. As of 2026 it does not have sufficient browser support to deploy in production without significant caveats. It as a format be aware of and watch, not to ship.

FormatTransparencyAnimationvs JPEG sizeEncoding speedBrowser support
JPEGNoNobaselineFast100%
PNGYesNolargerFast100%
WebPYesYes~30% smallerFast~97%
AVIFYesYes~50% smallerSlow~93%
JPEG XLYesYes~60% smallerSlowLimited
The practical decision rule

Hero photograph? Use AVIF as primary and WebP as fallback and JPEG as last source inside a <picture> element. UI graphics, product thumbnails, general content images? If you would like offer only one format the WebP should be your default. Logos and icons? SVG, every time.

Lossy vs Lossless: Understanding the Trade-off

The decision tree at the end of this lesson branches on a concept that the format descriptions above mentioned in passing but did not explain: lossy versus lossless compression. It’s worth taking a moment to understand what this distinction actually means, because it shapes the format decision for a significant category of images.

With lossy compression, the encoder permanently discards some image data. It does this intelligently by targeting subtle texture, fine grain, and other detail that the human eye is unlikely to notice under normal viewing conditions, but the result is a file that cannot be perfectly reconstructed into the original. JPEG is a lossy-only format. WebP and AVIF can both operate in lossy mode, which is their default for photographs.

With lossless compression, the encoder reduces file size without discarding any data. Every pixel value is preserved exactly, and the original image can be reconstructed perfectly from the compressed file. PNG is a lossless-only format. WebP and AVIF both support a lossless mode as an option.

A useful analogy: think of lossy compression like summarising a book for someone who wants the key ideas without reading every word. The summary is far shorter and captures most of what matters, but some detail is gone. Lossless compression is more like a ZIP archive, everything is still there, just packaged more efficiently. The original comes out complete when you unpack it.

When does the distinction matter? For photographs and images with smooth colour gradients, lossy compression works extremely well. The human eye is forgiving of small changes in photographic detail, and a well-tuned lossy encoder can cut file sizes by 60 to 80 percent with no perceptible quality loss.

For images with sharp text, fine lines, UI elements, or solid blocks of flat colour like screenshots, diagrams, icon exports saved as raster images, lossy compression introduces visible artifacts at edges and around letterforms. Lossless is the correct choice for those.

This is why the decision tree separates “photograph or complex gradients” from “contains text or hard edges” into different branches. The first group benefits from lossy. The second needs lossless.

Lossy quality is a dial, not a cliff

For lossy formats, you control the trade-off with a quality setting, typically a number from 0 to 100. The relationship is not linear: going from quality 60 to 80 produces a noticeable improvement in most images. Going from 80 to 95 is far subtler, while the file size increase is substantial. A quality of 80 for WebP and around 65 for AVIF are reliable starting points that land in the sweet spot for most photographic content. The result will be small files, minimal quality loss that is often imperceptible.

One Gotcha Worth Knowing: Colour Profiles

If you have ever exported a photograph from Lightroom, Capture One, or Photoshop and noticed that it looks vibrant and saturated on your screen but oddly flat or dull after you drop it onto a web page, you have encountered a colour profile mismatch. It is a common surprise and the fix is a single checkbox.

Cameras and design tools often embed colour profile data directly into the image file. This data tells the display device how to interpret the colour values in the image. The web is built on a colour space called sRGB, but professional photography and design tools frequently save images in wider colour spaces as Display P3 or Adobe RGB and these represent a broader range of colours.

When a browser encounters one of these wider profiles in an image, it handles the mismatch inconsistently across devices and operating systems. The result is colours that look wrong, or metadata overhead being carried around for no benefit to the user.

The fix is simple, always export images in sRGB and strip the embedded colour profile before serving. Most export dialogs have a “web” or “sRGB” colour space option. When you process images through @jsquash later in this series, the encoding step strips embedded profiles automatically.

Spot a colour profile problem in DevTools

If an image looks rich in your design tool but washed out on the page, open Chrome DevTools, go to the Network panel, click the image request, and switch to the Preview tab. If the preview looks fine but the rendered image in the browser looks muted, the embedded colour profile is likely the cause. The fix is to re-export from sRGB.

The Pre-Flight Decision Tree

Before any image enters an optimization pipeline, a quick pass through the following questions takes less than ten seconds and eliminates the most common sources of unnecessary file weight. This is the mental model you will use instinctively by the time you reach Lesson 12.

Loading diagram...

The only notable exception to this tree is high-fidelity photography for print-quality digital archives, where 16-bit colour depth and lossless encoding matter more than file size. For standard web delivery, the tree above covers everything you will encounter.

One path that deserves a specific call-out: never use GIF for animation. An animated GIF is typically 10 to 15 times larger than an equivalent animated WebP at the same visual quality. This is not a small difference. WebP animation has had near-universal browser support for years and there is no longer a practical reason to serve GIF files.

What about PNG?

PNG did not appear as the lead recommendation anywhere in this tree, and that is intentional. PNG is a lossless format designed for images with transparency and hard edges, things like screenshots and UI graphics. WebP lossless handles both of those use cases while producing smaller files. PNG remains relevant as a universal fallback when WebP is not an option, but it should not be your first choice.

What This Series Builds on Top of These Decisions

Understanding which format to target is the prerequisite for everything that follows. Knowing you want AVIF with a WebP fallback is useful insight. Knowing how to produce that AVIF inside the user’s browser, without a server, without ImageMagick, and without the raw file ever crossing the network, that is the engineering challenge this series addresses.

Netx lesson introduces @jsquash, the WebAssembly library that brings Squoosh-grade AVIF and WebP encoding directly into your application code. It explains what WASM is, how @jsquash wraps professional codec libraries, and what the decode-encode pipeline looks like before any Svelte appears.

Once you understand what the library is and why it is designed the way it is, building the actual optimizer becomes a matter of connecting pieces you already understand rather than trusting black-box magic.

Key Takeaways

  • SVG is code, not pixels. Use it for logos, icons, and illustrations. Always run exported SVGs through SVGO before deploying that can cut SVG file size upto 50%.
  • AVIF is the best available raster format for photography in 2026, with WebP as the universally safe fallback. JPEG should appear only as a last-resort fallback inside a <picture> element, never as your primary format.
  • Always export in sRGB and strip embedded colour profiles. Wide-gamut profiles like Display P3 and Adobe RGB add unnecessary file weight and can make images appear washed out across browsers. The fix is a single checkbox in your export dialog.

Further Reading

See Also

Continue learning
Squoosh as a Library @jsquash ports Squoosh's professional codecs to your browser via WASM - no server, no ImageMagick, no build step needed.
Lesson 3 14 min read
#performance#images