iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If a HEIC image previews in Safari but triggers an img error in Chrome, the likely explanation is uneven browser support: WebKit added HEIC support in Safari 17.0, while the Can I Use compatibility snapshot dated October 8, 2026 lists Chrome as unsupported. Treat onerror as a signal to recover—not proof that HEIC support is the only issue—and provide an alternate image or preview state.
Why Safari can show a HEIC image when Chrome cannot
HEIC is a high-efficiency image format used for photos in Apple’s ecosystem. WebKit announced HEIC support in Safari 17.0, including Safari View Controller and WKWebView on supported Apple platforms. That does not mean every browser using WebKit, or every Apple device configuration, behaves identically. The relevant capability depends on the browser engine, version, platform, and available image-decoding support.
The Can I Use HEIF/HEIC table, accessed October 8, 2026, lists Safari support beginning with version 17 and Chrome as unsupported in the versions shown. This is a dated compatibility snapshot, not a promise about every device, codec configuration, or future release. Check the HEIF/HEIC compatibility table for the browser versions you target.
In a browser that cannot load or render the supplied HEIC, an image element may fire an error event. MDN notes that an unsupported image format is one possible cause, but not the only one: an empty or invalid source, corrupted image data, or invalid metadata can also cause failure. The event therefore tells you the image did not load or render successfully; it does not identify the cause.
Choose a fallback based on who controls the image
| Approach | Useful when | Trade-off |
|---|---|---|
<picture> with alternate sources and an <img> fallback |
Your site controls the image assets and can provide multiple encodings. | You must create or serve alternate files; the browser selects among the sources and conditions you provide. |
| Attempt the HEIC preview, then show a converted preview or failure state | Users supply HEIC files and you cannot guarantee a pre-generated alternate. | Runtime failure can have several causes, and onerror alone does not prove unsupported HEIC is the cause. |
For images your site controls, offer alternatives in markup
The <picture> element lets the browser select among supplied image sources, with an <img> element as the baseline fallback. MDN recommends this pattern for image-format fallbacks. Choose formats according to the browsers you need to support: MDN describes AVIF as broadly supported and WebP support across Chrome, Edge, Firefox, Opera, and Safari. Keep a widely supported fallback if your audience includes clients outside the formats you provide.
For example, when you have a WebP asset and a JPEG fallback, the structure can be:
<picture>
<source srcset="/images/photo.webp" type="image/webp">
<img src="/images/photo.jpg" alt="A description of the photo">
</picture>This works for authored assets because you can supply the alternate files. It does not automatically convert an arbitrary HEIC file uploaded by a user.
For user-selected HEIC files, test the preview path and preserve recovery
For a user upload, do not decide that preview support exists only because a filename ends in .heic, or because the browser has a particular name. A filename describes a label, not whether this browser and device can render this particular image. No consistent, standardized cross-browser HEIC MIME-type test is established by the sources here, so avoid presenting one as definitive.
- Attempt the preview in the target image element. Treat successful rendering as the useful outcome, rather than relying on the extension or a browser-brand check.
- Handle the error event. If loading or rendering fails, switch to a converted preview when your application can provide one, or show a clear message that the image could not be previewed.
- Keep the failure path broad enough. Since invalid sources, network or loading problems, and damaged image data can also cause image errors, do not label every error as “HEIC unsupported.” Offer a retry or an alternate upload path when appropriate.
- Validate the implementation across your target clients. Feature detection is useful only when the actual preview path has been checked on the browser, version, and platform combinations your users rely on.
Use the error handler for recovery, not diagnosis
An onerror handler is valuable because it lets the interface respond when an image fails. It cannot, by itself, tell you whether the cause was HEIC decoding support, a bad URL, a network problem, or corrupt content. Keep diagnostics separate from the user-facing recovery state, and avoid reporting unsupported HEIC as a certainty unless another validated part of your application establishes that cause.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
