[HN Gopher] JPEG XL Test Page
___________________________________________________________________
JPEG XL Test Page
Author : roywashere
Score : 150 points
Date : 2026-01-21 16:38 UTC (6 hours ago)
(HTM) web link (tildeweb.nl)
(TXT) w3m dump (tildeweb.nl)
| p_ing wrote:
| Orion, and presumably other Webkit-based browsers that are
| actually up-to-date, can also see the image.
|
| Hopefully my photo processor will accept JPEG XL in the near
| future!
| nine_k wrote:
| Chromium 143 (the latest available in Void Linux, a rolling-
| release distro) still can't.
|
| The chrome://flags/#enable-jxl-image-format is not even found
| in the build :(
| RicoElectrico wrote:
| > Hopefully my photo processor will accept JPEG XL in the near
| future!
|
| Aren't print shops, machining shops, other small manufacturers
| etc. ones that always lag behind with emerging technologies?
| p_ing wrote:
| Yes, because those systems cost gobs of money. You don't
| replace them just for the hot new thing.
| sanjit wrote:
| Designers might also be hesitant to use an untested file
| format for print, too.
|
| If there's a large amount of paper that's been purchased for
| a job, I definitely wouldn't want to be the one who's
| responsible for using JPEG XL and - for whatever reason -
| something going wrong.
|
| Pixels are cheaper than paper or other physical media :)
| pkulak wrote:
| Yup, Gnome Web loads it just fine! Man, it really is a great
| browser. I try to switch to it every 6 months, but then I
| remember that it doesn't support extensions at all. I could
| give up everything, but not 1Password. Nothing is worth
| copy/pasting credentials and losing passkeys entirely.
| PlatoIsADisease wrote:
| Yep, doesnt work on firefox or chrome.
| _grilled_cheese wrote:
| Working fine on Firefox for me
|
| Firefox version 146.0.1 on Windows 11
| WithinReason wrote:
| https://caniuse.com/jpegxl
|
| I have the flag enabled but it's still broken in FF, needs to
| be a nightly build to work
| nticompass wrote:
| Works in Zen 1.17.15b (aka Firefox 146.0.1) on Linux.
| paularmstrong wrote:
| Same for me, Zen 1.17.15b on Mac
| Imustaskforhelp wrote:
| Same I am using Zen 1.17.15b on Mac too and it works for me
| too
| nor-and-or-not wrote:
| Same here, doesn't work, FF 148.0b5
| reef_sh wrote:
| On Waterfox. Image displays fine.
| blell wrote:
| Alright, that image made be really miss Lenna as an example
| image.
| volemo wrote:
| I understand why people avoid it now; however, having not seen
| the uncropped version for a long time initially, I have only
| warm associations.
| bigbuppo wrote:
| Looks like the sort of person that would create a superior image
| file format.
| antonyh wrote:
| Epiphany (aka Gnome Web) on Linux shows this correctly, as
| expected for a Webkit-based browser.
| oldcoot wrote:
| Looks like it works in Brave
| mdasen wrote:
| Weird, doesn't work in Brave (macOS) for me. Did you enable a
| setting? Brave says it's up to date when I check.
| iberator wrote:
| Doesn't work for me on Brave on Android
| Imustaskforhelp wrote:
| On zen. It works.
| dlcarrier wrote:
| Are there any up-to-date WebKit browsers for Android? The best I
| could find was Lightning, but it hasn't been updated in years.
|
| Edit: I found A Lightning fork called Fulguris. It didn't work
| with the JPEG XL test image, but I really like the features and
| customizability. It's now my default browser on Android.
| TingPing wrote:
| WPE can be built for Android, but it's not a user facing
| browser.
| zamadatix wrote:
| The closest thing I know of is Igalia has a project trying to
| port https://wpewebkit.org/ to Android
| https://github.com/Igalia/wpe-android and they have a
| minibrowser example apk in the releases of the current state
| (but I wouldn't call it a Chrome drop in replacement or
| anything at the moment - just the closest thing I know on
| Android).
| unglaublich wrote:
| I think JPEG XL's naming was unfortunate. People want to
| associate new image formats with leanness, lightness, efficiency.
| Almondsetat wrote:
| Do you have anything to back this up?
| snowram wrote:
| Considering "jpeg" has become the shorthand for "digital
| picture", it would be a shame not to capitalise on it.
| flexagoon wrote:
| I feel like "jpeg" has generally become a shorthand for "low
| quality compressed digital picture"
| dgan wrote:
| "diJital PEGchure"
| dlcarrier wrote:
| Is it pronounced jay-peg or gee-peg?
| goda90 wrote:
| Hence the meme response "Needs more jpeg" https://old.reddi
| t.com/r/explainlikeimfive/comments/2ct3ax/e...
| dylan604 wrote:
| I feel like you need to find better places on the internet.
| It's no longer 1997 downloading from dial up.
| notatoad wrote:
| What makes jpeg compression bad isn't low bandwidth. It's
| really good at compressing an image for that.
|
| What makes jpeg bad is that the compression artifacts
| multiply when a jpeg gets screen captured and then re-
| encoded as a jpeg, or automatically resized and
| recompressed by a social media platform. And that
| definitely isn't a problem that has gone away since
| dialup, people do that more than ever.
| bigbuppo wrote:
| Nah, that's WEBP, the most hated file format.
| benbristow wrote:
| In the photography world it's shorthand for "photo unedited
| straight from the camera". Popular with Fujifilm cameras
| especially due to their 'film simulation' modes which apply
| basically a filter to the image.
| doubletwoyou wrote:
| Not really? Unedited would be some sort of raw. JPEG
| usually implies preprocessed by the camera
| benbristow wrote:
| I guess I meant unedited by the photographer manually
| (e.g. using Lightroom etc.)
|
| Either that or a photo that has been edited from a RAW
| and is a final version to be posted online.
| zamadatix wrote:
| JPEG XS :D
| YakBizzarro wrote:
| https://en.wikipedia.org/wiki/JPEG_XS
| recursive wrote:
| Excess?!? I certainly don't want any of that in my image
| encoding formats!
| jonsneyers wrote:
| Exactly. Image compression should excel at avoiding
| excess.
|
| Though maybe some people think the JPEG committee is now
| creating spreadsheet formats...
| bobmcnamara wrote:
| I found it unfortunate because it's not a JPEG.
| Dwedit wrote:
| It has an operation mode where it can losslessly and
| reversibly compress a JPEG further, and "not a jpeg" wouldn't
| cover that.
| dragonwriter wrote:
| JPEG XL is the thing that makes your JPEG smaller?
| Dwedit wrote:
| JPEG XL is basically 4 codecs in one...
|
| * A new lossy image Codec
|
| * A lossless image codec (lossless modular mode)
|
| * An alternative lossy image codec with different kinds
| of compression artifacts than those typically seen in
| JPEG (lossy modular mode)
|
| * JPEG packer
|
| Because it includes a JPEG packer, you can use it as
| such.
| catskull wrote:
| mJPEG
| OscarTheGrinch wrote:
| Crappy as a .jpg, only bigger.
|
| Actually, I remember when JPEG XL came out, and I just thought:
| cool, file that one away for when I have a really big image I
| need to display. Which turned out to be never.
|
| Names have consequences.
| crazygringo wrote:
| > _Crappy as a .jpg, only bigger._
|
| Honestly, that's exactly what it sounds like to me too. I
| know it's not, but it's still what it sounds like. And it's
| just way too many letters total. When we have "giff" and
| "ping" as one-syllable names, "jay-peg-ex-ell" is
| unfortunate.
|
| Really should have been an entirely new name, rather than
| extending what is already an ugly acronym.
| sillysaurusx wrote:
| I'll never not say pee-en-gee. You're right though.
| NekkoDroid wrote:
| I always have called it PNG pee-en-ji, and JPEG XL for me
| has p much all the time been jay-x-el.
| gcr wrote:
| I regularly work with images larger than 65,535px per side.
|
| WEBP can only do 16,383px per side and the AVIF spec can
| technically do 65,535, but encoders tap out far before then.
| Even TIFF uses 32-bit file offsets so can't go above 4GB
| without custom extensions.
|
| Guess which format, true to its name, happens to support
| 1,073,741,823px per side? :-)
| fleabitdev wrote:
| There was a constraint - since 2009, the Joint Photographic
| Experts Group had published JPEG XR, JPEG XT and JPEG XS, and
| they were probably reluctant to break that naming scheme.
|
| They're running out of good options, but I hope they stick with
| it long enough to release "JPEG XP" :-)
| nocman wrote:
| Good one - made me and a coworker both LOL (in the literal
| sense) :D
| spider-mario wrote:
| Incidentally, JPEG Vista would be thematically appropriate.
| jonsneyers wrote:
| JPEG XP would have been a nice name for a successor of JPEG
| 2000, I suppose :)
|
| There's also a JPEG XE now
| (https://jpeg.org/jpegxe/index.html), by the way.
| lencastre wrote:
| JPEG ME
| formerly_proven wrote:
| Nobody can keep you from forking the spec and calling yours
| JPEG SM.
| kps wrote:
| Shouldn't that be JPEG(sm) vs JPEG(tm)?
| 12_throw_away wrote:
| > Nobody can keep you from forking the spec
|
| ISO: "Challenge accepted." [1]
|
| [1] https://www.iso.org/standard/85066.html
| edflsafoiewq wrote:
| Just call it JXL.
| ziml77 wrote:
| Pronounced jixel?
| spider-mario wrote:
| Pronounced like French << j'excelle >> (I excel).
|
| (Kidding.)
| ziml77 wrote:
| Kidding? But I actually kinda like it!
| greenavocado wrote:
| Yes, and JAY EXCEL for the savages like me
| F3nd0 wrote:
| It seems to me this point of discussion always tends to get way
| too much focus. Should it really raise concern?
|
| Of all the people who interact with image formats in some way,
| how many do even know what an image format is? How many even
| notice they've got different names? How many even give them any
| consideration? And out of those, how many are immediately going
| to think JPEG XL must be big, heavy and inefficient? And out of
| those, how many are going to stop there without considering
| that _maybe_ the new image format could actually be pretty
| good? Sure, there might be some, but I really don't think it's
| a fraction of a significant size.
|
| Moreover, how many people in said fraction are going to
| remember the name (and thus perhaps the format) far more easily
| by remembering it's got such a stupid name?
| bigbuppo wrote:
| And yet WEBP decided to associate itself with urine, which
| google then forced on everyone using their monopoly power.
| DominoTree wrote:
| JPEG 15 Pro Max
| ChrisArchitect wrote:
| Related:
|
| _Chromium Has Merged JpegXL_
|
| https://news.ycombinator.com/item?id=46597927
| sailfast wrote:
| Works on FireFox Focus on mobile, FWIW. (Latest iOS)
| cdmckay wrote:
| That's because it uses the WebKit renderer built in to iOS
| adzm wrote:
| Honestly I was hoping for a page showing off more of jpeg xl
| features rather than just a single image
| wmwragg wrote:
| You probably want the JPEG XL Info[1] site then. A nice site
| outlining what JPEG XL actually is.
|
| [1] https://jpegxl.info/
| amarant wrote:
| While I get why, it bugs me that they have comparison images
| between jxl and other formats, yet it doesn't actually use
| jxl, as evidenced by all images displaying correctly on my
| chrome browser.
| kps wrote:
| It uses jxl if the browser supports it, using <picture>1.
|
| 1 https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| uyzstvqs wrote:
| JPEG XL is also good, but why not use AVIF? It's widely supported
| by browsers, and rivals JPEG XL in being the best lossy image
| format.
| judah wrote:
| Jake Archibald has an excellent post about progressive image
| rendering, including some metrics on JPEG XL compared to
| AVIF[0].
|
| > "I was also surprised to see that, in Safari, JPEG XL takes
| 150% longer (as in 2.5x) to decode vs an equivalent AVIF.
| That's 17ms longer on my M4 Pro. Apple hardware tends to be
| high-end, but this could still be significant. This isn't
| related to progressive rendering; the decoder is just slow.
| There's some suggestion that the Apple implementation is
| running on a single core, so maybe there's room for
| improvement.
|
| > JPEG XL support in Safari actually comes from the underlying
| OS rather than the browser. My guess is that Apple is
| considering using JPEG XL for iPhone photo storage rather than
| HEIC, and JPEG XL's inclusion in the browser is a bit of an
| afterthought. I'm just guessing though.
|
| > The implementation that was in Chromium behind a flag did
| support progressive rendering to some degree, but it didn't
| render anything until ~60 kB (39% of the file). The rendering
| is similar to the initial JPEG rendering above, but takes much
| more image data to get there. This is a weakness in the decoder
| rather than the format itself. I'll dive into what JPEG XL is
| capable of shortly.
|
| > I also tested the performance of the old behind-a-flag
| Chromium JPEG XL decoder, and it's over 500% slower (6x) to
| decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder
| is about as slow as the Safari decoder. It's not fair to judge
| the performance of experimental unreleased things, but I was
| kinda hoping one of these would suggest that the Safari
| implementation was an outlier.
|
| > I thought that "fast decoding" was one of the selling points
| of JPEG XL over AVIF, but now I'm not so sure.
|
| > We have a Rust implementation of JPEG XL underway in Firefox,
| but performance needs to get a lot better before we can land
| it."
|
| [0]: https://jakearchibald.com/2025/present-and-future-of-
| progres...
| quentindanjou wrote:
| I am curious, isn't AVIF also taking advantage of the
| hardware decoding democratized by AV1?
| michaelt wrote:
| Taking advantage of hardware decoding is generally like
| pulling teeth.
|
| For video you can't avoid it, as people expect several
| hours of laptop battery life while playing video. But for
| static images - I'd avoid the pain.
| Socket-232 wrote:
| Why use AVIF when JPEG XL is much better and in a few weeks
| almost universally supported?
| F3nd0 wrote:
| Because JPEG XL is the first format to actually bring
| significant improvements across the board. In some aspects AVIF
| comes close, in others it falls far behind, and in some it
| can't even compete. There's just nothing else like JPEG XL and
| I think it deserves to be supported everywhere as a truly
| universal image codec.
| gary_0 wrote:
| If I download the image, Fedora KDE shows it properly in Dolphin
| and Gwenview.
| jordemort wrote:
| Works in Waterfox (6.6.8)
| davidhyde wrote:
| Works with Waterfox on macOS but curiously not Firefox. I wonder
| if their search deal with Google included keeping the
| image.jxl.enabled setting off.
| quaintdev wrote:
| Works on Zen as well.
| F3nd0 wrote:
| That's an interesting speculation, but I'm inclined to believe
| their official reasoning. (That being they just didn't really
| care about the format and/or went with whatever Chrome said at
| first. A year or so later they changed their mind and said they
| wanted an implementation in a memory-safe language, which
| prompted the JXL team to work on it.)
| ajdude wrote:
| > this means only Safari will display the image, as far as I
| know.
|
| Works fine for me in Orion on both desktop and mobile (
| https://orionbrowser.com ).
| seanclayton wrote:
| Which makes sense as Orion uses the same engine as Safari.
| jbverschoor wrote:
| Cannot see it with lockdown mode iOS
| rhdunn wrote:
| Works in ladybird as well.
| Redster wrote:
| I can see the image just fine on Thorium!
| hotsalad wrote:
| I enabled image.jxl.enabled in LibreWolf and works. It doesn't
| work in Firefox Beta, though?
| Frenchgeek wrote:
| There's a jpeg xl viewer extension available for firefox.
| samtheDamned wrote:
| A rare win for gnome web over firefox here
| numbers wrote:
| I'm seeing the image on zen which is a firefox fork but not on
| firefox itself :/
|
| even with `image.jxl.enabled` I don't see it on firefox
| capitainenemo wrote:
| Checking the Firefox bugs on this, it seems they decided to
| replace the C++ libjxl with a rust version which is a WIP, to
| address security concerns with the implementation. All this
| started a few months ago.
|
| Maybe the zen fork is a bit older and still using the C++ one?
| capitainenemo wrote:
| ... update. after reading the comments in the rust migration
| security bug, I saw they mentioned "only building in nightly
| for now"
|
| I grabbed the nightly firefox, flipped the jxl switch, and it
| does indeed render fine, so I guess the rust implementation
| is functioning, just not enabled in stable.
|
| ... also, I see no evidence that it was ever enabled in the
| stable builds, even for the C++ version, so I'm guessing Zen
| just turned it on. Which... is fine, but maybe not very
| cautious.
| awestroke wrote:
| zen browser is pretty much vibe coded
| dietr1ch wrote:
| Flipping `image.jxl.enabled` made it work for me after
| refreshing the page. I'm using Librewolf 146.0.1-1, but I guess
| it works just fine in firefox 146
| cubefox wrote:
| According to CanIUse, no browser implementation currently
| supports progressive decoding [1]. This is unfortunate, since
| progressive decoding theoretically is a major advantage of JPEG
| XL over AVIF, which doesn't allow it in principle, even though
| ordinary JPEG allows it. But apparently even a default (non-
| progressive) JPEG XL allows some limited form of progressive
| decoding [2]. It's unclear whether browsers support it though.
|
| 1: https://caniuse.com/jpegxl
|
| 2: https://youtube.com/watch?v=inQxEBn831w
| senfiaj wrote:
| Starting from v145 Chrome supports JXL.
|
| There is also an extension for this:
| https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...
| pkulak wrote:
| And Firefox: https://addons.mozilla.org/en-
| US/firefox/addon/jxl/
| jiggawatts wrote:
| Support is not a boolean.
|
| A proper test page should have HDR images, images testing if
| 10-bit gradients are posterised to 8-bit or displayed smoothly,
| etc...
|
| iOS for example can show a JPEG XL image, but can't forward it in
| iMessage to someone else.
| mattlondon wrote:
| Presumably the "January 2027" statement is a typo, ...or is that
| when it is slated to launch in safari?
| roywashere wrote:
| yeah, it's a typo :-)
| gcr wrote:
| One thing I like about JPEG-XL is that it supports all kinds of
| weird image formats.
|
| For example, I used to work with depth data a lot, which is best
| expressed as monochrome 16-bit floating point images. Previously,
| TIFF was the only format that supported this. Many shops would
| instead save depth images as UINT16 .PNG files, where the raw
| pixel intensity maps to the camera distance in mm. The problem
| with this is that pixels more than 65.535 meters away aren't
| representable. (Hot take: I personally think this is one reason
| why nobody studies depth estimation for outdoor scenes.)
|
| JPEG-XL supports more weird combinations here, e.g. storing
| greyscale float32 images (with alpha even! you can store sparse
| depth maps without needing a separate mask!)
|
| It's like, uniquely suited to these sorts of 3D scene
| understanding challenges and I really hope people adopt the
| format for more scientific applications.
___________________________________________________________________
(page generated 2026-01-21 23:00 UTC)