Why Do We Need a New Image File Format?
New image formats balance file size, visual quality, features, speed, and browser support. Learn how to choose one and serve fallbacks safely.
We need new image file formats because images have competing needs: small files, high visual fidelity, fast encoding and decoding, broad compatibility, and features such as transparency, animation, high dynamic range, and progressive display. A newer format can combine capabilities or improve the size-quality tradeoff for some images, but no format is best for every image or audience.
For a website, choose by image type and target browsers, then test representative files. WebP and AVIF are useful choices for many raster images; use lossless encoding for screenshots, diagrams, logos, and line art when compression artifacts would be distracting. Keep a JPEG or PNG fallback where browser support requires it. These are practical guidelines, not a rule that every image should use the same extension. MDN’s image format guide explains the tradeoffs and fallback approach.
Why not just use JPEG?
JPEG remains useful, especially for photographs and compatibility, but an image format is more than a compression ratio. A format also determines how transparency, animation, color profiles, metadata, bit depth, and dynamic range are represented. JPEG does not cover every combination of those needs in one format.
Compression is another tradeoff. Lossy compression reduces file size by discarding image data; lossless compression preserves enough information to reconstruct the original exactly. A photograph may tolerate some lossy compression, while text, sharp edges, diagrams, and screenshots can reveal ringing, blur, or other artifacts. A format that performs well on one image may perform poorly on another.
New formats try to improve one or more of these tradeoffs. The goal is not novelty: it is to deliver an image that looks right, has the needed features, works in the intended software, and costs an acceptable amount to encode and transfer.
What changes between image formats?
- Compression and fidelity: how much data the format can remove or represent compactly at a chosen visual quality.
- Image features: support for alpha transparency, animation, metadata, color profiles, wide color gamut, HDR, high bit depth, layers, or thumbnails.
- Progressive display: whether a partial download can show a useful preview before the complete image arrives.
- Encoding and decoding cost: the time and computing resources needed to create and display an image.
- Compatibility: whether the browsers, operating systems, apps, image pipelines, and publishing tools used by your audience can handle the format.
These dimensions interact. A smaller encoded file may take longer to create or decode. A format may have useful features but not be supported across the applications your workflow depends on. The right comparison uses the same source images, delivery sizes, and acceptable quality levels.
What do WebP, AVIF, and JPEG XL offer?
WebP
WebP supports both lossy and lossless compression, alpha transparency, and animation. Its container can carry metadata and color profiles. The IETF describes it as an image format optimized for efficient transfer, covering use cases associated with JPEG, PNG, and GIF. That combination illustrates why a newer format can be useful: one format can cover several kinds of image and feature requirements. See RFC 9649.
AVIF
AVIF is another option for web images. Mozilla’s published examples show it producing smaller files than JPEG XL for the particular lossy web-quality comparisons in those examples. That does not mean AVIF will be smaller for every image or setting; content and encoder settings matter.
JPEG XL
JPEG XL is designed for web and professional imaging. The JPEG Committee describes support for wide color gamut, HDR, high bit depth, animation, alpha, layers, thumbnails, lossless coding, and progressive coding. It also supports lossless recompression of existing JPEG files, with restoration of the original JPEG, which can help preserve existing JPEG workflows. See the JPEG Committee’s JPEG XL overview.
Mozilla’s August 2026 comparison illustrates why there is no universal winner. In its examples, AVIF files were smaller at two lossy quality points, while JPEG XL files were smaller in the cited lossless comparisons. The results varied by image: for a photograph, lossless JPEG XL was smaller than lossless AVIF and WebP; for a screenshot, lossless JPEG XL was smaller than lossless AVIF. Those are examples from a particular set of encodes, not a general benchmark. Mozilla recommends testing representative images and settings. Read Jake Archibald’s Mozilla Hacks article for the test details and browser-status discussion.
Which image format should I use?
| Image or requirement | Starting point | What to check |
|---|---|---|
| Photographs | Compare WebP and AVIF at the visual quality you need; retain a compatible fallback if required. | Fine texture, banding, file size, encode/decode cost, and audience support. |
| Screenshots, text, diagrams, logos, and line art | Try lossless encoding or a suitable lossless format. | Inspect small text and sharp edges at the actual display size; lossy artifacts can be conspicuous. |
| Transparent images | Choose a format with alpha support, such as WebP, AVIF, or PNG where appropriate. | Check transparency rendering and the applications in your publishing workflow. |
| Animation | Compare formats that support animation, including WebP and AVIF. | Check playback behavior, file size, and target browser support. |
| Large, high-resolution raster images or professional imaging | Evaluate JPEG XL when your tools and audience support it. | Check HDR, wide color, bit depth, progressive display, and the current compatibility situation. |
| Scalable diagrams and charts | Consider SVG where the content and delivery context suit vector graphics. | Ensure the graphic is appropriate for vector delivery and that its content is safe to publish. |
Use the table as a shortlist, not a substitute for testing. The best result depends on the source, the chosen encoder and settings, the rendered dimensions, and the clients you need to support.
How do I serve modern formats with fallbacks?
Use the HTML <picture> element to offer preferred formats and provide a fallback image in <img>. The browser selects a supported source. The fallback should match the image’s needs: JPEG is often suitable for a photo, while PNG can preserve transparency or sharp pixel detail.
<picture>
<source type="image/avif" srcset="/images/product.avif">
<source type="image/webp" srcset="/images/product.webp">
<img src="/images/product.jpg"
alt="A product shown on a desk"
width="1200"
height="800">
</picture>For responsive images, provide candidate sizes with srcset and a sizes attribute on each source and the fallback image. Keep the alternatives equivalent in composition and crop, and provide useful alternative text on the fallback <img>. Consult MDN’s picture element reference for markup details.
Browser support changes. Before deploying a format, check current compatibility for the actual browsers and devices your users rely on, as well as support in your image editor, build pipeline, and content management system. A browser may support decoding while a separate tool in your workflow does not support encoding or previewing.
How should I compare formats for my site?
- Build a representative sample. Include photographs, screenshots, diagrams, transparent assets, and other image types you actually publish.
- Set a quality target. Compare decoded images at the dimensions and quality your users will see. Do not compare one format at a much lower visual quality than another.
- Encode each sample. Record output size and encoding time, and inspect difficult areas such as text, gradients, fine texture, and transparency edges.
- Check delivery and decode behavior. Measure in your real serving path and target browsers. Consider progressive display and the cost of decoding on the devices that matter to your audience.
- Verify fallbacks end to end. Test unsupported formats, missing files, cache behavior, and responsive source selection.
- Revisit the choice when support changes. Browser and tool support evolves, so compatibility should be checked before a rollout rather than assumed from an old compatibility snapshot.
Smaller image resources can reduce transfer time and may help Largest Contentful Paint, but the outcome depends on the image, encoding settings, network, cache, and rendering path. Google’s web.dev image performance guidance covers image delivery in the context of page performance. Do not assume a fixed page-speed gain from changing extensions.
Or skip the browser setup
If you need a rendered page image while evaluating formats or documenting a page, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. See the API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots, and every feature is available on every plan.
Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.
Troubleshooting image format rollouts
The image is broken in some browsers
Cause: A client cannot decode the selected format, or the source URL is wrong. Fix: Include a working fallback inside <img>, confirm the file is deployed, and check current support for the affected browser.
The image looks worse even though the file is smaller
Cause: Lossy settings removed detail, or the comparison used different quality targets. Fix: Re-encode at a suitable quality and inspect the decoded image at its actual display size. For text, diagrams, screenshots, logos, and crisp edges, try lossless encoding.
A transparent image has a solid background
Cause: The chosen encoding path or conversion discarded alpha. Fix: Confirm that the chosen format and encoder preserve transparency, then test the delivered asset against both light and dark backgrounds.
The browser requests the fallback instead of the preferred source
Cause: The source type, MIME type, markup, or file URL is incorrect, or the browser does not support that source. Fix: Check the type value, server response type, URL, and browser support; verify source selection in browser developer tools.
The new format takes longer to build or display
Cause: Encoding or decoding cost offsets some transfer savings for the workload or devices involved. Fix: Measure build time and page behavior on representative hardware, compare encoder settings, and choose a practical balance rather than optimizing file size alone.
Frequently asked questions
Will modern image formats work in my browser?
It depends on the format and browser version. Check current compatibility for your audience and provide a fallback where needed. Support can change, so verify it close to release.
Does the newest format always make the smallest file?
No. Results depend on image content, encoder, settings, and quality target. Compare representative images instead of relying on a universal ranking.
Should I convert my whole image library?
Only after checking visual quality, compatibility, tooling, and the cost of conversion and storage. A gradual rollout with fallbacks can reduce deployment risk.
Are screenshots good candidates for lossy compression?
Sometimes, but text and sharp edges expose artifacts readily. Start with lossless encoding or inspect lossy output carefully at the size users will see.
