Browser image format support: test the encoder and the destination
Understand the difference between decoding, encoding, and displaying an image format, and verify capabilities in the browser doing the work.
A browser may be able to display a format without exposing a reliable way for a web application to encode it. Support can also vary by operating system, hardware path, browser release, and the Wasm assets delivered by the application.
Decode, encode, and display are different
Displaying an image means the browser can decode bytes that already exist. Creating a new file requires an encoder exposed through a browser API or supplied by application code such as a Wasm module. A compatibility table that says a format is viewable does not prove that a browser utility can generate it.
Ziply probes the current environment and uses its local Worker, Rust/Wasm artifacts, and supported browser codecs. A format remains locked or unavailable when the required local path is missing rather than sending the file to a server as a fallback.
Why support changes between devices
Browser engines ship on their own schedules, and some media functions rely on operating-system components. Enterprise policies, privacy settings, memory limits, and older devices can change which path succeeds. Private browsing may also reduce storage available for caching the application shell.
That is why a production check should use the actual artifact and device classes you intend to support. A successful developer-machine test is useful evidence, but it is not a substitute for the browser matrix.
A practical cross-browser test
Use a small set containing an opaque photo, a transparent graphic, a screenshot with text, and a high-detail image. In each target browser, generate every advertised output, reopen the downloaded file, confirm dimensions and transparency, and compare the signature and MIME type with the selected format.
Also test batch cancellation, repeated runs, offline reload after the required assets have been cached, and a file close to the plan limit. Record browser and operating-system versions with the evidence so a later regression can be reproduced.
- Chrome and Edge should be tested separately even though they share an engine family.
- Include Firefox and Safari/WebKit because codec and Worker behavior can differ.
- Open outputs in the destination product, not only in the browser tab.
- Verify the application refuses animated inputs it cannot preserve safely.
Plan for fallback without hidden uploads
A capability failure should be visible. Ziply does not turn an unsupported local format into a cloud-encoding request. Choose another available output, change browser, or retry on a device with the required capability.
For public web delivery, keep a widely compatible variant until traffic and destination support justify removing it. Modern formats are valuable, but operational resilience comes from deliberate fallback rather than assuming every consumer updates at the same time.