One heavy image creates two visible problems
A large photograph can leave an empty space on a page for too long. Compress it too aggressively and the image may load faster, but the reader sees blurred detail, banding in gradients, or damaged text. Modern formats offer different ways to find a better balance between file size and visible quality.
JPEG XL is a file format for photographs, screenshots, and other graphics. It is designed to reduce file size while targeting the required quality, support lossless compression, and progressively refine an image as it downloads. Web teams can evaluate it as an alternative to AVIF, WebP, or JPEG.
On August 24, 2026, Mozilla announced its intent to enable JPEG XL in Firefox. That makes the format worth examining, but it does not prove availability across all stable browsers. The practical question is this: which format performs best on your files and works in the browsers your audience uses?
How a format and codec reduce file size
A format defines the file structure. A codec is software or an algorithm that encodes an image into a file and decodes it for display. Lossy compression discards some data to reduce file size. It often suits photographs when changes remain invisible under predefined quality criteria.
Lossless compression allows exact pixel values to be restored. It can be important for graphics or screenshots containing small text. The format name alone cannot guarantee the best result: image type, encoder settings, required quality, processing time, and visitor browsers all matter.
JPEG XL, AVIF, or WebP: what to test first
| Format | Good starting cases | What must be checked |
|---|---|---|
| JPEG XL | Large photos, lossless images, existing JPEG files | Stable browsers, progressive display, encoder mode |
| AVIF | Web photographs and images combining sharp edges with flat color areas | Detail, gradients, color, and encoding time |
| WebP | A control option when WebP is already part of the image pipeline | Quality at a comparable file size and actual audience coverage |
There is no universal winner. One format may work better for photographs and another for screenshots or lossless graphics. A successful result from one file does not represent the whole media library.
Why JPEG XL is interesting
Mozilla highlights three capabilities. JPEG XL supports lossless compression. Mozilla also says it can reduce the size of already compressed JPEG files without introducing another loss of quality. That matters when another lossy encoding step is undesirable.
Another capability is progressive display when the browser implementation supports it. A large file can first produce a rough but recognizable image and then refine it. This does not remove the need to set correct dimensions, deliver an appropriately sized file for the display, or measure page performance.
Intent to add a format is not stable-release support
As of August 24, 2026, Mozilla had announced its intent to enable JPEG XL in Firefox and reported a similar intent from Chrome. The same article said that Safari shipped a JPEG XL implementation in 2023, but Mozilla described it as partial and noted that it did not support progressive display.
These statements describe development status on the source date. They do not guarantee that the format works in every stable release. Interop 2026 includes an investigation intended to make JPEG XL testable across browsers, including work to define progressive-rendering requirements. Participation in that effort is not proof of ready support.
The supplied sources do not provide a complete matrix of current stable versions as of publication. Before using the format on a site, record the date and test JPEG XL in the current stable Firefox, Chrome, and Safari versions actually used by your audience. An experimental build or a feature enabled behind a flag is not a substitute for that check.
How an image fallback works
The picture element can offer several sources. A browser evaluates the source elements in order and selects the first compatible source. If it does not support JPEG XL but does support AVIF, it can proceed to the AVIF source. If no source matches, it uses the conventional JPEG from the img element’s src attribute:
<picture>
<source srcset='/images/hero.jxl' type='image/jxl'>
<source srcset='/images/hero.avif' type='image/avif'>
<img src='/images/hero.jpg' alt='Image description' width='1600' height='900'>
</picture>
Choose the order and fallback file from your own tests. Do not delete originals or existing fallback files merely because a sandbox page opened in one browser.
A safe test with an AI assistant
1. Understand the decision first
Give the assistant only this article, the glossary, and dated public sources. Permit it to explain terms and ask comprehension questions. Prohibit file changes, choosing a winning format, or treating browser intent as released support. Stop if an explanation cannot be checked against a source. The expected artifact is four short explanations covering image formats, the two compression types, stable support, and fallback delivery. Verify them yourself and restate them in your own words before allowing any changes.
2. Inspect a sample without changing files
Give the assistant a local copy or anonymized inventory with pixel dimensions, file sizes, formats, a delivery markup or configuration snippet, and aggregated browser shares. Permit only metadata reading, grouping, and sample selection. Prohibit writing, secret access, private-image uploads, and invented data. Stop if file provenance or permission is unclear. The artifact is a sample table. Manually compare several rows with the filesystem and confirm that the sample covers the image types actually used on the site.
3. Create a reproducible plan
Provide the verified table, visible-quality criteria, target browsers, and a requirement to preserve originals. The assistant may propose a reproducible encoding and comparison procedure, commands, a fallback, and a rollback method. It may not declare a winner or replace measurements with its judgment. Stop if quality criteria, browser targets, or rollback are missing. The artifact is an experiment plan. Check commands against encoder documentation and confirm that the plan cannot touch the production environment.
4. Act only on copies
Allow a small sample to be encoded in a temporary directory, test repository, or separate branch. The assistant may also create a sandbox page and command log. Prohibit source overwrites, fallback removal, production access, recording repository changes, or merging a branch without separate approval. Stop if an encoder is missing, a command attempts to overwrite a source or escape the test environment, or a file cannot be opened. Inspect the changes, compare checksums—the digital fingerprints of the originals—and rerun the commands on a clean copy.
5. Verify the result yourself
A person must lead this stage. Measure actual file sizes, inspect details at the same scale, and test preferred and fallback files in recorded stable browser versions. Repeat the test on a throttled connection. The artifact is a matrix containing the date, browser versions, measurements, and failed cases. Compare its numbers with the files and command log. A confident assistant conclusion is not evidence.
6. Record a bounded decision
Give the assistant only verified measurements, approved criteria, and compatibility sources with recorded dates. It may draft a short decision record recommending further testing, postponement, or use for a specific image class with a fallback format. Prohibit generalizing from one file or hiding negative results. Stop if numbers conflict with the log or the result cannot be reproduced. A responsible person must check every number and support claim before approving the record.
Practical conclusion
Treat JPEG XL as a candidate for a controlled test, not as a reason to re-encode an entire site immediately. Base the decision on your own images, the stable browsers used by your audience, and a verified fallback path.
Sources
- Mozilla Hacks: https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
- Interop 2026 on web.dev: https://web.dev/blog/interop-2026?hl=en
- MDN, the
pictureelement: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture
Quick checklist
- Define whether you are testing photographs, screenshots, or lossless graphics.
- Record the target browsers, their stable versions, and the test date.
- Preserve originals and current fallback files outside the test directory.
- Compare images with identical pixel dimensions and predefined quality criteria.
- Verify size, appearance, loading, and fallback behavior manually.
- Limit the decision to the tested image class rather than the entire media library.