JPEG XL Test Page

Original Article ↗ Hacker News Discussion ↗

Current Browser Support and Variability

  • Many reports of JPEG XL working in Safari/WebKit-based browsers (Safari, Orion, Gnome Web, Epiphany, Ladybird, various forks) and some Firefox derivatives (Zen, Waterfox, LibreWolf with flags).
  • Mixed behavior in Firefox: some need Nightly builds or hidden flags (image.jxl.enabled), others see no support in stable despite toggling it.
  • Chrome/Chromium: older builds lack support or the flag; newer Chrome (v145+) reportedly adds JXL; Brave support is inconsistent across platforms.
  • On iOS, support often comes via WebKit at OS level (including Firefox Focus), but some modes (e.g., Lockdown) break it, and JXL can’t always be forwarded in apps like iMessage.

Print and Professional Workflow Concerns

  • Some hope print/photo labs will accept JXL soon; others argue such vendors lag due to expensive, long‑lived equipment.
  • Debate over whether labs “should” convert customer formats themselves; one side says they must match customer files exactly, the other says lossless conversion to supported formats is part of the job.
  • Designers may be reluctant to risk new formats on costly print runs; “pixels are cheaper than paper.”

Naming, Branding, and Perception

  • Several commenters dislike “JPEG XL” as a name, associating “XL” with bloat or “crappy JPEG but bigger,” and finding “jay‑peg‑ex‑ell” clumsy versus short names like GIF/PNG.
  • Others argue it’s smart to leverage “JPEG” brand recognition, which for some means “digital photo,” for others “low‑quality compressed image.”
  • Jokes and alternatives: JXL (“jixel”), μJPEG, JPEG XS/XE/XP, playful puns (“JPEG Extra Lovely”), and comparisons to WEBP’s unfortunate connotations.

Technical Capabilities and Performance Debates

  • Some see JPEG XL as uniquely strong: supports very large dimensions, many bit depths, HDR, float formats, and can act as:
    • a new lossy codec
    • a lossless codec
    • a different-artifact lossy mode
    • a “JPEG packer” that losslessly recompresses legacy JPEGs.
  • It’s praised as better than AVIF “across the board” by some; others ask “why not AVIF,” citing its wider current support.
  • One cited blog claims Safari and experimental Chromium/Firefox decoders show JXL decoding 2.5–6× slower than AVIF, contradicting earlier claims that JXL is faster; another benchmark (Cloudinary) reportedly found JXL faster, leading to confusion about implementations and settings.
  • Progressive decoding is highlighted as a theoretical advantage over AVIF, but CanIUse data suggests no current browser supports full progressive JXL; there’s uncertainty about partial/proxy progressive behavior.

Security, Implementations, and Extensions

  • Firefox removed an earlier C++ libjxl and is working on a Rust implementation for security; JXL is only enabled in Nightly/Labs for now.
  • Some forks ship the C++ version enabled by default, which others view as less cautious.
  • Commenters note image parsing’s long RCE history, supporting the push for memory-safe implementations.
  • Chrome is said to also rely on a Rust JXL implementation, which was key to merging support.
  • Browser extensions and WASM decoders are suggested as stopgaps, but there’s pushback against installing powerful third‑party extensions just to view an image format.

Test Pages and Feature Coverage

  • A few users want richer demos (HDR, 10‑bit gradients, more feature exercises) rather than a single test image.
  • JPEG XL info/test sites are shared; they reportedly use <picture> to serve JXL where supported and fallback formats otherwise, which some initially misunderstood.
  • One commenter notes that “support is not boolean”: OS or browser might decode but not fully integrate (e.g., lack of sharing support).

Niche and Scientific Use Cases

  • JPEG XL is praised for handling “weird” formats: grayscale float images, depth maps (float16/float32), alpha channels for sparse data, etc., improving over earlier solutions like TIFF or uint16 PNG depth maps with real-world range limits.
  • Another commenter observes that this richness and complexity likely increases library size and attack surface, which could make browser vendors wary compared to simpler formats like WebP (viewed as a single-frame video derivative).

Miscellaneous Threads

  • Side remarks on nostalgia for the Lenna test image and why it’s now avoided.
  • Observations that iOS/macOS “Live Text” (text selection in images) works with JXL in Safari, but that’s an OS feature, not a JXL capability.
  • Light banter comparing Safari’s JXL lead to IE‑style divergence, and minor language/typo commentary on the test page itself.