Vyso Blog
What’s the Best Image Format for the Web? (Hint: It Depends)
There is no universally best image format for the web. A photograph, a screenshot and a vector logo have different requirements. The choice also depends on visual fidelity, transparency or animation, browser support and how the image reaches its consumer.
Preserve the source separately from its web outputs. One JPEG source can produce a WebP representation for a product card, an AVIF representation for another placement and a JPEG compatibility output. The application chooses which representations to expose.
Format, dimensions and quality are separate decisions
Format names describe only part of the result:
- Format: JPEG, PNG, WebP, AVIF or SVG determines the encoding and its capabilities.
- Dimensions: the width and height determine how many pixels are delivered.
- Quality and encoder settings: these determine compression behavior, including which detail is retained and how much work encoding requires.
Choosing a modern format does not fix an image that is far larger than its rendered size. Format selection works alongside sizing and compression; it cannot replace those decisions.
Start with the kind of image
A fixed ranking such as AVIF > WebP > JPEG > PNG ignores the content and delivery goal. Narrow the candidates by what the image needs to show:
- Vector artwork: consider SVG for logos, icons, diagrams and simple interface illustrations made from paths and shapes.
- Photographs and continuous-tone images: compare JPEG, WebP and AVIF at the intended display size.
- Screenshots, small text and sharp UI graphics: start with PNG or lossless WebP. Test AVIF if its output preserves the detail you need.
- Transparency: PNG, WebP and AVIF can carry alpha. Check the edges against the backgrounds where the image will appear.
- Animation: evaluate animated WebP, APNG, animated AVIF where supported, or video for longer and more complex motion.
A product photograph and a screenshot of a pricing table have different failure points. The photograph may tolerate some changes in fine texture. The screenshot needs readable text and clean boundaries between colors.
JPEG: reliable for photographs and compatibility
The JPEG files normally used on websites use lossy compression. JPEG works well for photographs, gradients and other continuous-tone imagery, with broad browser compatibility and mature editing and encoding tools. It remains a practical choice when predictable tooling or a simple fallback matters. Conventional web JPEG has no alpha channel. MDN’s image format guide
Lossy compression allows a range of visual tradeoffs; it does not mean the image must look poor. Strong compression can introduce artifacts around edges and discard fine detail. Choose settings by inspecting the output in its actual placement.
Progressive JPEG can display an initial coarse image and refine it as more scans arrive. That affects how the image appears during loading, separately from its final quality. The libjpeg-turbo documentation describes both progressive encoding and the tradeoff between quality settings and file size.
Keep a source available for future exports. Repeatedly decoding and saving a JPEG with lossy compression can add further changes; converting it to another format cannot recover detail already discarded.
PNG: lossless raster detail and transparency
PNG uses lossless compression and supports alpha transparency. It is a useful candidate for screenshots, diagrams and raster graphics where exact pixel detail matters. These capabilities are defined in the PNG specification.
PNG is often inefficient for photographs compared with lossy JPEG, WebP or AVIF outputs. A photograph’s texture can require many bytes to preserve exactly, even when a smaller lossy representation would look acceptable on the page.
PNG compression settings control how the pixel data is encoded. They are not equivalent to JPEG’s lossy quality setting. Resizing or reducing a palette before encoding can still change the image: lossless encoding preserves the data supplied to the encoder, not every earlier stage of the workflow.
For a logo that exists as vector artwork, consider SVG first. PNG is appropriate when you specifically need a raster export or the artwork contains raster detail.
WebP: a flexible modern raster format
WebP supports lossy and lossless compression, alpha transparency and animation. That makes it a useful general-purpose raster output for a mixture of photographs and graphics. The WebP container specification defines those capabilities.
Choose the encoding mode deliberately. Lossy WebP is a candidate for photographs; lossless WebP is worth comparing with PNG for screenshots and sharp graphics. A high quality setting on a lossy encoder is not a substitute for selecting lossless mode. Google’s WebP encoder documentation treats quality, lossless mode and encoding effort as separate controls.
WebP has broad support in modern browsers. It can simplify a delivery strategy, but compare representative outputs before choosing it for every asset. The result still depends on content and settings.
AVIF: efficient compression with different tradeoffs
AVIF can produce compact images at strong visual quality. Its capabilities include lossy and lossless encoding, alpha transparency, higher bit depths and support for HDR and wide-gamut content. Those capabilities require an appropriate encoding and display pipeline; choosing the extension alone does not create HDR content. AOMedia’s AVIF overview
AVIF is a strong option, not a universal winner. File size and appearance depend on the source, encoder, quality and speed settings, chroma configuration and alpha data. Chroma subsampling reduces color detail, which deserves particular attention around small colored text and sharp edges.
Encoding cost belongs in the comparison. Slower AVIF settings can require more processing, which matters when outputs are generated on demand. The libavif encoder exposes separate controls for speed, color quality, alpha quality and chroma format. Its lossless mode also checks whether the chosen settings permit lossless output.
Loading behavior needs its own check. The AVIF specification allows layered progressive decoding, and libavif can encode layered outputs. Whether a particular file displays progressively depends on its encoding and the decoder. Test the delivered file in your supported browsers; AVIF’s format name alone does not guarantee the loading behavior of progressive JPEG.
SVG: keep vector artwork as vectors
SVG describes shapes, paths and text, and can also include raster images. For inherently vector artwork, it can scale without the pixelation of a fixed raster export. Logos, icons, line art and simple diagrams are common uses. The SVG specification describes its graphics model.
Simple artwork can have a small SVG payload. Complex paths, filters and embedded raster images can make an SVG heavy. Putting a photograph inside an SVG does not make the photograph resolution independent or remove its transfer cost.
Untrusted SVG uploads need a separate security decision. SVG is XML-based and can contain scripts or external references; which features can run depends on how it is served and embedded. The SVG processing modes define those differences. Apply an explicit upload and serving policy, as discussed in the user-image upload guide.
GIF, APNG and animated images
GIF retains very broad compatibility, but its limited color palette and compression make it inefficient for many photographic animations. Palette reduction can also change the appearance before the frames are compressed. APNG provides lossless raster animation with alpha; WebP and AVIF also support animated content. MDN’s format guide
For new work, compare the candidates using the actual animation. Check frame timing, transparency, payload and browser support for animation specifically. For a longer sequence or complex motion, include video in the comparison. Still-image support alone is an insufficient test for an animated delivery workflow.
Source format and delivery format can differ
The source format is what you preserve as the canonical media asset. The delivery format is what a particular consumer receives.
A JPEG source can produce WebP and AVIF representations for web delivery, plus a JPEG representation for a compatibility requirement. A PNG source can produce a WebP representation while remaining unchanged in storage. Choose output settings for the required detail and transparency.
There is no need to replace the source merely because the website uses another format. Keeping it separately lets you create new crops, dimensions or formats later. Retention remains a workflow decision, but generating each output from the preserved source avoids a chain of already-compressed derivatives.
Browser selection and server negotiation are different models
WebP and AVIF have broad support in current Chrome, Edge, Firefox and Safari releases. Compatibility still depends on the browser versions, operating systems and embedded clients your audience uses. MDN maintains separate support data for WebP and AVIF.
Explicit selection with picture
The frontend can offer format alternatives through <picture>. Assuming these representations are available, a format-only example is:
<picture>
<source srcset="/photo.avif" type="image/avif">
<source srcset="/photo.webp" type="image/webp">
<img src="/photo.jpg" alt="Ceramic bowl on a wooden table">
</picture>
The browser selects the first supported source in this example. If neither source type is supported, it uses the <img> URL. The application supplies the alternatives and their order; this is not a search for the smallest file. MDN’s picture documentation explains source selection and fallback behavior.
This fallback covers unsupported formats. It is not a promise that a failed AVIF request will automatically retry as WebP or JPEG.
Not every site needs three formats for every image. Choose the alternatives your browser matrix requires, accounting for your framework, encoding cost, storage and maintenance. Format choice determines the encoding; responsive image markup determines which size candidate the browser selects. Width selection through srcset and sizes is covered in the responsive-images guide.
Server or CDN negotiation
Some serving systems inspect request headers such as Accept and choose a supported representation at delivery time. If one URL can return different formats, the cache must distinguish those responses. Standard HTTP negotiation uses Vary to identify the request headers involved in selection. MDN’s content-negotiation guide
Explicit format URLs put the format choice into the representation’s identity. Vyso currently uses this explicit model: the consuming application chooses a transformation or preset, and the CDN returns its output. Browser or device detection is not part of Vyso’s current format selection. The CDN caching guide covers representation reuse and invalidation.
Compare formats at the required visual quality
Format, dimensions and encoder settings are separate decisions. A modern format cannot compensate for delivering far more pixels than a placement needs. A 6000×4000 AVIF used for a 300-pixel-wide card can still be wasteful, even after allowing for a high-density display. A correctly sized JPEG can be a reasonable result.
A codec leaderboard is less useful than testing representative images at acceptable visual quality. Keep the source, crop and output dimensions consistent. Encode the candidates, inspect them at the intended display size, then compare bytes at a visual quality you can accept. Check fine texture, gradients, text and transparent edges where those matter.
The same numeric quality value across encoders does not mean equivalent visual quality. Avoid comparing “quality 80” files as though the number standardized their fidelity. A fixed percentage-savings table would also hide the effects of content and settings.
The image quality and performance guide covers that workflow in more depth. Format selection also leaves loading decisions to the page: an efficiently encoded image still costs bytes if downloaded unnecessarily.
Practical format comparison
These are format capabilities, not a list of options exposed by every image service. “Lossless” assumes a suitable encoding mode and compatible preprocessing.
| Format | Raster or vector | Lossy | Lossless | Alpha | Animation | Typical fit |
|---|---|---|---|---|---|---|
| JPEG, conventional web encoding | Raster | Yes | No | No | No | Photographs, compatibility outputs |
| PNG / APNG | Raster | No | Yes | Yes | With APNG | Screenshots, exact raster detail, lossless animation |
| WebP | Raster | Yes | Yes | Yes | Yes | Photographs, graphics, animated raster content |
| AVIF | Raster | Yes | Yes | Yes | Yes | Efficient photographic delivery, alpha or HDR workflows when supported |
| SVG | Vector, can include raster | Not applicable | Not applicable | Yes | Yes | Logos, icons, diagrams, simple illustrations |
Lossless WebP, animated outputs and HDR in this table describe format capabilities. They do not imply that Vyso exposes those encoding modes or workflows.
A quick decision guide
- Identify the content. Keep real vector artwork as SVG where appropriate. Compare JPEG, WebP and AVIF for photos; PNG and lossless WebP for precise raster graphics.
- Check required capabilities. Transparency, animation, exact pixel fidelity or HDR narrow the candidates. Test the specific feature, not just support for the extension.
- Define the consumers. Use your audience’s browser matrix to decide whether JPEG or PNG fallbacks are needed.
- Compare real outputs. Keep dimensions consistent, inspect quality and measure transfer size and encoding cost.
- Choose the delivery model. Expose explicit alternatives or use a serving system with verified negotiation and cache behavior. Preserve the source separately.
Where Vyso fits
Vyso preserves the uploaded source and supports explicit JPEG, PNG, WebP and AVIF outputs through transformation chains or saved presets. jpg and jpeg select the same JPEG encoder. The output-format documentation describes the available format choices.
Representations are generated when requested and can be cached; uploading the source is a separate step.
Your application chooses the requested format, dimensions and quality settings. Common chains can be saved as presets; frontend markup or application logic determines which output URLs consumers receive. Vyso executes those requested transformations, without automatically negotiating AVIF, WebP and JPEG fallbacks from browser or device capabilities.
The response Content-Type identifies the delivered representation. A transformed URL can retain a source asset key ending in .jpg while returning image/webp. Inspect the response header when checking a conversion. The current output encoder list covers JPEG, PNG, WebP and AVIF; SVG, GIF and JPEG XL generation are outside that list.
The best web image format meets the content and compatibility requirements at an acceptable visual quality and transfer cost. Preserve the source separately, then choose the delivery representation deliberately.
Keep going
Make the media library less work.
See how Vyso brings search, enrichment, cleanup, and delivery into one product.
Start free