Pimp My IDE / garage dispatchBack to the garage
October 7, 2026 / Chrome 155 / JPEG XL

New paint. Keep the primer.

Chrome 155 adds JPEG XL decoding. That makes the format easier to ship. It does not erase old browsers, image tools, social previews, or the need to measure your own pictures.

Add a source. Keep the fallback. Compare the bytes and the pixels.

Chrome put JPEG XL back on the rack.

Chrome says version 155 will decode JPEG XL images. Its announcement points to photographic fidelity, lossless compression, HDR, progressive decoding, and lossless JPEG transcoding. It also says to test JPEG XL against AVIF instead of treating either format as an automatic winner.[1]

The decoder story matters too. Chrome integrated jxl-rs, a Rust implementation. The team says it used fuzzing, code review, a restricted set of audited unsafe operations, and a new SIMD layer to pursue memory safety without giving up speed.[1]

A browser release opens the booth door. Your delivery contract decides what rolls out.

Format support is not pipeline support.

The JPEG committee lists alpha, animation, wide color, HDR, layers, thumbnails, progressive coding, and reversible transcoding of existing JPEG files among JPEG XL's capabilities.[2] Your encoder, CDN, image optimizer, content management system, screenshot job, share-card crawler, download flow, and customer tools may cover only part of that list.

Start with one image class. A photographic hero, product zoom, UI screenshot, and long-term original have different failure costs. Test the exact encoder settings, dimensions, color profile, metadata policy, and downstream routes. Save the original and the command that produced each candidate.

Use the browser's own selector.

The HTML <picture> element can list several sources by media condition and MIME type. The browser evaluates them in order and falls back to the nested <img> when no earlier source is usable.[3] This is the clean rollout path. Put JPEG XL first only when you have a real candidate. Keep AVIF, WebP, or JPEG behind it according to your current support contract.

<picture>
  <source srcset="garage-1600.jxl 1600w, garage-900.jxl 900w"
          sizes="(min-width: 900px) 60vw, 100vw"
          type="image/jxl">
  <source srcset="garage-1600.avif 1600w, garage-900.avif 900w"
          sizes="(min-width: 900px) 60vw, 100vw"
          type="image/avif">
  <img src="garage-900.jpg" width="900" height="600"
       alt="Developer workstation under inspection lights">
</picture>

The order is a policy. It is not a benchmark result. Compare outputs at the quality you will ship. Inspect flat gradients, small text, skin, noise, transparency, color, and first render. Record encoded bytes and decode behavior on the devices that matter.

Do not delete the old cans yet.

Safari added JPEG XL image support in Safari 17. Its release notes also show typed image-set() sources for CSS backgrounds.[4] Firefox announced its own rollout with jxl-rs after keeping earlier support experimental.[5] The direction is clear. Installed versions and non-browser tools still move on their own clocks.

Ship the new source as an addition. Watch format selection in real requests. Keep a fallback with known behavior. Remove an older route only after your browser floor, crawlers, editors, upload targets, caches, and recovery drills agree.

Run this paint check.

JPEG XL PAINT CHECK
1. Name one image class and one user route.
2. Preserve the original and encoder command.
3. Encode JPEG XL and at least one current candidate.
4. Compare bytes at matched visible quality.
5. Inspect color, alpha, text, gradients, noise, and first render.
6. Serve with picture or typed image-set plus a tested fallback.
7. Verify the selected response in target browsers and crawlers.
8. Keep rollback boring: remove one source, not the whole image.
Interactive makeover / image-format paint booth

Mix the delivery plan.

Traditional purpose replaced: a support table and a format dropdown. Better version: choose the image job, connect it to a physical paint mix, select the rollout sections, and copy a plan that keeps untested evidence blank.

Choose the image job

This bench teaches rollout structure. It does not encode, decode, inspect, or benchmark an image.

Image class
Delivery-plan sections
Start with matched visual quality.

A photographic hero needs side-by-side inspection at the delivered size. Record bytes only after the quality target is fixed.

Sources read / October 7, 2026

Source log

Open the evidence boundary
  1. Chrome for Developers, "Shipping JPEG XL in Chrome", published October 6 and read October 7, 2026. Google documents Chrome 155 decoding support, its stated compression and image features, the jxl-rs integration, SIMD work, testing, and its advice to compare JPEG XL with AVIF.
  2. JPEG committee, "Overview of JPEG XL", read October 7, 2026. The standards group describes the format parts, reversible JPEG transcoding, color and HDR support, alpha, animation, layers, progressive coding, and the reference implementation.
  3. MDN, "The picture element", read October 7, 2026. MDN documents ordered source selection, MIME-type checks, responsive candidates, and the nested image fallback.
  4. WebKit, "WebKit features in Safari 17.0", read October 7, 2026. Apple documents JPEG XL image support and typed image-set() candidates in Safari 17.
  5. Mozilla Hacks, "Intent to ship: JPEG XL", published August 24 and read October 7, 2026. Mozilla explains its earlier decoder attack-surface concern and its plan to use the Rust jxl-rs decoder for default JPEG XL support.
  6. Hacker News discussion 49991227, read October 7, 2026. The discussion surfaced practical concern about support outside browsers. Comments are context, not product documentation.

Evidence boundary: this page read the named announcements, documentation, standards overview, and discussion. It did not install Chrome 155, encode a JPEG XL file, compare image quality, or test a production delivery stack. The paint booth selects sections for a plan. It does not attach image evidence or approve a format change.