JPG to JXL
Write a JPG out as JPEG XL. This goes through pixels, so what lands is a fresh encode, not the lossless repack of the original JPEG bytes.
JPG to JXL reads the file as pixels and encodes them from scratch, which is not the trick JPEG XL is known for. Packing an existing JPEG whole and giving the identical bytes back needs the box container and its reconstruction data. What lands here is a bare codestream with no way back to the original bytes.
Questions
Is this a lossless repack of the JPEG bytes?
No, even though some JPEG XL tools offer exactly that elsewhere. This pipeline decodes the JPG to pixels first and encodes fresh JPEG XL data from them, a real re-encode rather than a lossless bit-for-bit repack.
What is lost?
Nothing beyond what the source JPEG already lost, plus whatever choices the JPEG XL encoder makes at the chosen quality, default 80. Since the repack path is not used, this is a second generation of lossy encoding rather than a free container change.
Which engine handles this?
jSquash decodes the JPG through mozjpeg and encodes JPEG XL through its own WebAssembly encoder. Both run in Node, on the command line, through MCP and in the browser.
What size should I expect?
Usually smaller than the source JPG, since JPEG XL compresses more efficiently than JPEG at a comparable visual quality, even working from an already lossy source.
What is the reverse page?
There is none. JPEG XL to JPG is not one of the named pairs, though Convert image can decode a JXL source and write JPG from it directly.