Convert WebM to JXL

Every other still format on this site has somebody demanding it. A records system specifies TIFF. A performance budget forces AVIF. An email needs a JPG and a bug report needs a PNG. JPEG XL has no such constituency: no upload form lists it, no archive standard requires it, and no colleague has ever asked for one.

That means this page owes you an assessment rather than instructions. You have read that JXL compresses better than what you are using and you are deciding whether to switch, which is a reasonable thing to be doing and is worth doing with the actual behaviour of this conversion in front of you rather than the format’s specification.

JPEG XL’s reputation rests substantially on lossless coding — it can store an image exactly, and it can repack an existing JPEG losslessly and smaller. Neither is what happens here. Frame extraction offers one option, the timestamp, and hands the decoded frame to the shared image encoder, which uses a fixed quality of 82.

Eighty-two is a sensible number for a photograph and it is still lossy. So a JXL produced on this page is a compressed approximation of a frame that was already a compressed approximation, and describing it as an archival master would be wrong twice over. If that is not what you expected, it is better to find out in a paragraph than in three years.

If nothing further should be discarded, the PNG route is the one that delivers it. PNG stores exactly what the decoder produced and stops, and the resulting file then goes through a lossless optimisation pass that rewrites it more efficiently without changing a pixel.

The trade is size, and on screen content it is smaller than people expect, because large flat areas of one colour are the case PNG was designed for. Take the JXL when you have thousands of frames and per-image size is the constraint you are managing; take the PNG when the frame is evidence, documentation, or the only copy of something.

One image at a smaller size is not worth changing your tooling for. A thousand images is a different arithmetic, and that is the case this conversion suits: a monitoring archive with a frame per recording, a research set sampled across hundreds of sessions, a personal collection where the storage bill is a real number.

At that scale a modern codec against an older one is a meaningful fraction of a disk, and the fact that few things open a JXL matters less, because the files are being read by your own scripts rather than passed around. The moment any of them has to be sent to somebody, the calculation reverses entirely.

The registry records browser support for JPEG XL as partial rather than universal, and lists GIMP and ImageMagick as the software that reads it. Both of those are accurate and both understate how awkward it is in practice: a JXL cannot be relied on to render in a web page, to preview in a file manager, or to open on somebody else’s machine.

Plan for that rather than discovering it. Keep a JPG or a PNG alongside anything that might need to be shown to a person, and treat the JXL as the stored copy rather than the working one. An archive whose format nobody can read is a backup with extra steps.

The image comes out at the video’s native pixel dimensions with nothing scaled, and each conversion produces exactly one of them. Building a set means converting repeatedly with different timestamps — type a number, convert, download, change the number — which takes a couple of seconds a time because nothing is uploaded in between.

That is a reasonable way to pull a dozen stills out of a session and a poor way to pull a thousand. For a genuinely large sampling job, a command-line tool with a frame-rate flag is the right shape, and saying so is more useful than pretending a browser form scales to it. Use this for the frames somebody has chosen.

JPEG XL, like the other modern still codecs, is tuned for photographic content: gradients, texture, detail that changes smoothly. Screen recordings are the opposite — hard edges, flat panels, thin lines and small type — and lossy encoders put a faint halo around exactly those transitions.

At quality 82 that halo is mild and it is there, and it lands on the part of a screen capture somebody actually needs to read. If the frame exists because an error string, a field value or a menu item has to be legible in it, this is the wrong conversion regardless of how the file sizes compare. That reader is served by the lossless route.

Most of what makes JPEG XL interesting is about photographs. High bit depth for raw conversions, an alpha channel, EXIF and ICC profiles carried through an editing chain, lossless recompression of an existing JPEG library. Those are real advantages and none of them is reachable from a video frame.

The frame arrives through a canvas at eight bits per channel, fully opaque, with no camera metadata, no capture timestamp and no colour profile — because a browser recording never had any. What is left of the format’s case here is compression efficiency alone, which is a narrower argument than the one that usually persuades people to adopt it.

The WebM is decoded in the tab with the codecs the browser already ships, one frame is encoded, and nothing carrying the video is transmitted. There is no account and no daily count, and the free tier accepts files up to 100 MB.

For this reader that is more than a principle, because the recordings being sampled are usually screen captures — sessions, dashboards, internal tools, whatever else happened to be visible. Uploading an entire recording to retrieve a single still is a poor trade even before anyone asks where it went.