Choosing JPEG, PNG, WebP or AVIF for an Article
A content-first decision table and a comparison workflow without invented savings.
Choose a format and an encoding mode for what the reader needs to see. Photographs are good candidates for lossy JPEG, WebP or AVIF. Small-text screenshots and sharp diagrams deserve a lossless starting point. Transparency, animation, browser decoding and the publishing toolchain are separate requirements; no format wins every comparison.
- Start with the image's job
- A filename does not specify the encoder settings
- Protect the information in screenshots
- A reproducible comparison to perform on your own assets
- Browser support and downstream reuse are different tests
- Finish with useful markup and text alternatives
Start with the image's job
An original selection guide, not a measured ranking| Article asset | Starting candidates | Acceptance check |
|---|---|---|
| Photograph | JPEG, lossy WebP or lossy AVIF | Recognizable detail at the intended display size, then actual encoded bytes. |
| Screenshot with small labels | PNG or an explicitly lossless WebP/AVIF export | Characters, thin lines, color handling and the smallest important detail. |
| Logo or diagram | Keep an appropriate vector SVG source; for a bitmap, compare PNG and lossless WebP/AVIF. | Clean boundaries, readable labels and expected scaling. |
| Transparent raster image | PNG, WebP or AVIF with alpha preserved by the exporter | Edge pixels against light and dark backgrounds; JPEG cannot retain alpha. |
| Animation | A format and exporter that preserve the required frames and timing | Actual playback in the intended browser and publication path, not just the first frame. |
The distinction between photos and hard-edged artwork is documented in the MDN format guide. The table is an editorial starting point for selecting candidates, not a promise about file size. An illustrative article containing a landscape, a terminal screenshot and a transparent logo has three different fidelity needs.
A filename does not specify the encoder settings
WebP and AVIF can use lossy or lossless encoding. A modern extension therefore does not prove that pixels were preserved. Even a lossless codec mode does not undo a resize, color-space conversion, bit-depth change or earlier lossy export performed before encoding. Keep the reference image and record the whole recipe.
Transparency is independent of losslessness. Google's WebP documentation describes alpha support with both lossy and lossless WebP. The approved AVIF 1.2.0 specification, dated October 16, 2025, also supports alpha through auxiliary image data. Whether your editor exports it correctly remains a toolchain check.
Renaming photo.png to photo.webp changes the name, not the encoded bytes. Use an actual encoder or export function. Google's cwebp and dwebp guide documents real conversion tools. No installation or conversion was performed to produce this article.
Protect the information in screenshots
A screenshot can look broadly recognizable while its smallest useful text becomes blurred or fringed. For a terminal error, that missing character may be the point of the image. Start with a lossless export, keep dimensions comparable, and inspect important characters at the article's intended display size.
If a diagram already has an appropriate SVG original, keep that vector source. Moving a bitmap between raster formats does not create vector geometry or recover detail that was discarded. Avoid repeatedly saving an already lossy candidate as the source for the next candidate.
A reproducible comparison to perform on your own assets
- Keep untouched originals separately. Define one reference crop, pixel dimensions and color treatment for each asset.
- Encode every candidate from that same reference. Record the tool and version, format, lossy/lossless mode, alpha/animation requirements and changed options.
- Inspect candidates at the same intended display size. Check screenshot text, diagram edges, photo detail, transparency and motion as applicable.
- Choose an explicit visual acceptance requirement before comparing bytes. Encoder “quality 80” values are not interchangeable measurements across codecs.
- Record actual sizes only for files you generated. Check import, save, publication and final display in the real destination.
This is a proposed workflow, not an experiment whose results we measured. There are no claimed conversion savings or quality scores here. A format that produces the smallest acceptable file for one photograph need not win for another image or for a screenshot.
Browser support and downstream reuse are different tests
Use a suitable picture fallback where needed: an opaque photo may fall back to JPEG, while an asset requiring transparency or lossless sharp detail may need PNG. A fallback that drops the image's required information is not equivalent. Check the actual browser versions and encoded features you support.
Website decoding does not establish what an email client, desktop editor or content-management upload pipeline accepts. Keep alternate deliverables when they are required. Still-image support also does not establish animation, HDR or every profile supported by a specification.
Finish with useful markup and text alternatives
Supply accurate intrinsic width and height so the browser can reserve an aspect ratio before loading. Responsive CSS can still scale the image. Format selection and stable layout solve different parts of the publishing problem.
The W3C WAI alt decision tree selects text alternatives according to purpose. Give an informative image the meaning it contributes; use an empty alt="" for a purely decorative image. A functional image needs the action or destination, while a complex chart needs its information available in text as well. Alt text is not a place to repeat a list of search keywords.
For source identity and reuse checks, see verifying citations. For a separate hardware illustration of independent capabilities, see USB-C power, data and display support.
Generated with Ithy Pro; AI-assisted editorial and primary-source checks completed October 23, 2026. The three independent model perspectives are retained with corrections. Original examples and test limits are identified.
Primary references
Compare the AI responses
Read each model’s complete response below.
GPT-6 Luna
Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.
Choose by image content, transparency needs, delivery compatibility, and the result of comparing encodes—not by a universal format ranking. JPEG is a lossy option for photographs; PNG is lossless and supports transparency; WebP and AVIF can be encoded lossily or losslessly, so the format name alone does not determine quality. Lossy encoding can blur small screenshot text and add fringes around sharp edges. Keep original files, compare versions at identical dimensions, and judge visual quality before choosing a smaller file. The supplied evidence does not establish current email/editor compatibility or detailed browser support for AVIF, so test those needs separately. Describe meaningful images with alt text, and specify intrinsic width and height to help reserve layout space.
- Start with the image’s content and required features. For a photograph, JPEG is a straightforward lossy fallback; WebP or AVIF are also candidates, but each can be encoded either lossily or losslessly. For screenshots, diagrams, logos, or line art, prefer lossless encoding because blur and colored fringes around text and edges are conspicuous. PNG is lossless and supports transparency; JPEG has no alpha channel. A logo available as vector artwork may be better served as SVG, which MDN identifies as suitable for diagrams and icons. [1.1] [1.2] [4.2]
- | Article image | Practical starting point | What to check | |---|---|---| | Photograph | Compare JPEG with lossy WebP or AVIF | Look for visible detail loss at the displayed size | | Text-heavy screenshot | PNG or lossless WebP/AVIF | Inspect small text and sharp edges; avoid lossy damage | | Logo or diagram | SVG if suitable vector source exists; otherwise PNG or lossless WebP/AVIF | Check edge clarity and whether transparency is needed | | Transparent image | PNG as a fallback; compare WebP/AVIF where supported | Confirm the alpha channel survives the chosen encoding | This is a use-case guide, not a ranking: WebP and AVIF’s lossy/lossless behavior is an encoder choice, and the best result depends on the actual image and settings. [1.2] [1.4] [4.2]
- Treat format capability and encoder settings as separate decisions. WebP and AVIF each support lossy and lossless encoding; JPEG is lossy and PNG is lossless. Thus, saying “use AVIF” or “use WebP” does not by itself specify whether image data is discarded. For text-heavy screenshots, lossy compression can produce visible blur or colored fringes, which is why MDN recommends lossless encoding for screenshots and other sharp-edged artwork. [1.1] [1.2]
- Use a reproducible comparison rather than assuming a format wins: retain an untouched original; make candidate encodes from that same original; use identical pixel dimensions and intended crop; compare them at the same display size; and inspect the details that matter for that content, such as fine text, edges, gradients, or photographic texture. Record each format’s encoder and settings, then compare file sizes only among versions whose visual quality is acceptable for the same use. This is a proposed workflow, not a report of tests or measured savings.
- Do not convert an image by merely changing its filename extension. The extension is a label; the image must actually be encoded in the target format. Use an encoder or conversion tool and verify the resulting file. Google’s WebP documentation identifies cwebp as a conversion tool and describes WebP as image data in a RIFF-based container. [2.2] [2.3]
- Separate browser delivery from the file’s underlying capability. MDN says to use the HTML picture element to provide fallback formats for browsers that do not allow newer formats. That supports offering alternatives, but the supplied evidence does not establish a complete current browser-decoding matrix for AVIF or every browser version. Likewise, it does not verify current email-client or editor compatibility: test the actual browsers, email clients, publishing tools, and upload pipeline relevant to the site instead of assuming web-browser support guarantees support elsewhere. [6.6]
- For animated images, WebP documentation says animated WebP can support lossy or lossless encoding and transparency. That establishes a WebP capability, not that every editor, email client, or browser workflow handles animated files alike. Confirm animation and transparency in the actual destination before replacing an existing asset. [2.1]
- Write alt text for the image’s meaningful content rather than stuffing it with search terms; this is practical accessibility guidance, not a ranking promise. Set the image’s intrinsic width and height in the HTML so the browser can calculate its aspect ratio before loading and reserve space, which MDN says can reduce or prevent layout shift. [4.3] [4.4]
The supplied primary-source excerpts do not establish current AVIF decoding support by browser/version, or current email-client and editor compatibility. Verify these against current official compatibility documentation and the actual publishing workflow.
Claude Haiku 5.5
Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.
Choose according to content fidelity, actual encoder settings and delivery requirements. Small text and sharp edges deserve a lossless starting point; photos may tolerate lossy encoding. PNG, WebP and AVIF can preserve alpha when the exporter supports it, while JPEG cannot. The checked main article adds direct AOM AVIF and W3C accessibility references; it reports no conversion benchmark.
- For screenshots, diagrams, logos and line art, MDN recommends lossless encoding because blurring and colored fringes around text and sharp edges are very visible. Photographs and continuous-tone images can usually tolerate lossy compression, since discarded detail is harder to see. [1.1] [1.2]
- PNG is lossless and is suited to screenshots, diagrams and line art, and it is the fallback for images needing transparency because JPEG has no alpha channel. JPEG is lossy and is often a good fallback for photographs. [1.2] [6.3]
- WebP and AVIF support both lossy and lossless compression as a setting chosen at encoding time, so picking a format does not by itself fix quality; the encoder setting matters. The MDN compression table lists PNG as always lossless and JPEG as always lossy, with WebP hybrid and AVIF lossy or lossless. [1.2] [10.1]
- Published compression comparisons depend on their input images, dimensions, settings and acceptance criteria. They are not measurements from this article. Compare your actual exports from a common reference rather than projecting a vendor percentage onto every photograph or screenshot.
- Google documents lossy and lossless animated WebP with transparency. The approved AOM AVIF specification also defines image sequences and alpha. Check the actual exporter and destination for required motion, timing, color and transparency; no codec-tooling maturity ranking was measured here.
- Use a suitable browser fallback and test the actual publishing destinations. Browser decoding, email-client display, social-card import, animation and editor export are separate capabilities. No current universal email or social-client compatibility matrix was measured or verified here.
- Renaming a file's extension does not convert it. The format is determined by the encoded data, so a conversion must re-encode pixels with an encoder (for example cwebp or a graphics editor). This is an inference from the encoding model described in the sources, not a statement a source makes directly.
- Practical guidance: keep original files; for each image, choose a lossless or lossy setting according to content, test the same dimensions at the same visual quality, add width and height attributes so the browser can reserve space, and write alt text that describes the content. Avoid claiming any format always wins or that a ranking will improve from these choices. [4.3] [4.4]
Sources do not establish a universal size saving; reported percentages depend on test images and quality metrics that vary by source.
Current email client support for AVIF and WebP was not confirmed from primary email-client documentation in the supplied passages.
Claude Sonnet 5.5
Editorial source check: October 23, 2026. This independent research perspective is retained with factual corrections; the checked main article adds current primary references and the stated examples.
Choose by image content and required features, not by one winner. MDN says lossless encoding suits screenshots, diagrams, logos and line art because blurring and colored fringes around text and sharp edges are very visible, while photographs tolerate lossy compression. WebP and AVIF can be lossy or lossless depending on encoder settings; JPEG is lossy and has no alpha, and PNG is lossless. SVG is preferred for vector logos and diagrams. Use picture fallbacks for compatibility, keep email and social images conservative, and set width and height to reduce layout shift. Third-party size and support figures are vendor or blog claims, not measured here. I ran no tests.
- MDN separates lossy from lossless: lossy discards data for smaller files, lossless reproduces the original exactly. For screenshots, diagrams, logos and line art it advises lossless encoding because blurring and colored fringes around text and sharp edges are very visible. This is why small text in screenshots suffers under lossy encoding. [1.1] [6.2]
- Photographs and other continuous-tone images usually tolerate lossy compression because the discarded detail is harder to see. MDN calls JPEG a good fallback for photographs. WebP and AVIF can serve photos too, with lossy settings chosen at encoding time. [1.2]
- Codec capability is not the same as the file you produced. PNG is always lossless and JPEG always lossy, but WebP and AVIF can be either, depending on the encoder setting. Renaming photo.png to photo.webp does not convert it, because the bytes remain the original format. That follows from WebP being a RIFF container holding VP8 or VP8L data (inference), so a real encode with a tool such as cwebp is required. [10.1] [1.2] [2.2] [2.3]
- PNG, WebP and AVIF support alpha, while JPEG does not. AVIF 1.2.0 specifies auxiliary alpha image data and image sequences. Capability in a format does not establish what each editor exports or each destination decodes; verify the actual files and requirements.
- For logos and diagrams, prefer SVG when a vector source exists, since it draws accurately at any size. If only a bitmap exists, MDN names PNG as the fallback. Lossless WebP is another option a third-party guide suggests, but verify it in your own workflow. [1.4] [4.2] [3.3]
- Use a suitable browser fallback and test the actual publishing destinations. Browser decoding, email-client display, social-card import, animation and editor export are separate capabilities. No current universal email or social-client compatibility matrix was measured or verified here.
- Accurate width and height let the browser reserve an aspect ratio. W3C WAI bases alt text on purpose: communicate useful meaning or function, use empty alt for purely decorative content and supply a textual explanation for complex information. These are reader-facing requirements, not a ranking promise.
- Suggested optional workflow, as guidance: keep untouched originals, export each candidate from the same master at identical pixel dimensions, record encoder name and settings, and compare on the same display. Inspect small text, edges and gradients at 100% zoom, then compare file sizes only in your own results. Compare lossless with lossless and lossy with lossy. Any numbers in third-party posts are illustrative, not results from this article. [1.1] [2.3] [5.5]
Current browser and email support figures come from secondary or snippet sources, not official support tables.