HEIC browser support: Chrome, Safari, Firefox, Edge

The practical situation

Safari 17 and later on Apple platforms can display HEIC, using the codec the operating system provides; earlier Safari versions could not, even on the same hardware. Chrome, Edge and Firefox generally cannot decode HEIC on their own, so an image element pointing at a .heic file fails.

Support changes over time, so treat any specific claim as something to verify rather than assume.

The underlying pattern is consistent, though. Browsers that rely on the operating system for media decoding inherit whatever the system supports, while browsers that ship their own decoders support only what the project has chosen to include.

Why browsers differ at all

A browser can decode an image in two ways: with a codec built into the operating system, or with one bundled inside the browser. The first approach keeps the download small but ties behaviour to the platform. The second gives consistent results everywhere but adds code and, in the case of HEVC, licensing questions.

HEVC is the sticking point. Its patent situation is a strong reason for browser projects to decline to bundle a decoder. Where the operating system already provides one, there is less incentive to add another.

This is why the same page can render correctly on one machine and not on another, and why HEIC support is better described as a platform capability than as a browser feature.

What happens when a page links a HEIC

If the browser cannot decode the file, the image element fails. Depending on the page, that shows as a broken image icon, an empty space, or an alt text fallback. There is usually no explanation, because from the browser's point of view the markup was valid and the image type was unsupported.

Background images fail the same way and often more quietly, leaving a blank panel with no visible error. A link that opens the file directly may prompt a download instead, because the browser cannot render it and offers to save it.

Occasionally a file downloads rather than displaying even when the browser could handle the content, because the server sent a content type the browser did not recognise or a disposition header asking for a download.

MIME types and file extensions

The registered media type for the format is image/heic, with image/heif covering the wider family. A server that serves a HEIC as a generic binary stream or labels it image/jpeg creates confusion: a browser may refuse a type it could have handled, or trust a label that misdescribes the bytes.

Extensions carry no authority on the web. What a browser acts on is the content type reported by the server, so a file renamed to .jpg does not become a JPEG. Renaming to force a viewer to accept a file tends to make the failure less clear rather than smaller.

For a site that wants to serve HEIC to capable clients, the honest approach is to send the correct type and let other clients fall back to a converted copy.

Options for showing HEIC on a website

The right answer depends on who the images are for. A photography site that wants original quality may decode on demand; a general website is usually better served by converting once and storing the result.

• Convert the image ahead of time and serve JPG, PNG or AVIF.
• Generate several formats and let the browser choose with a picture element.
• Decode the HEIC in JavaScript, typically with a WebAssembly build of a decoder, and draw the result to a canvas.
• Transcode on the server when the upload arrives, and store the converted copy.
• Serve the HEIC only as a download, with a converted preview beside it.

What to do as a user

If a HEIC will not open, you have two options: open it on a device that supports it, or convert it to a format the browser can read. Converting to JPG or PNG is enough for display, and this site's viewer decodes HEIC in the browser without uploading it.

Which you pick depends on what comes next. If you are sending the file onwards, converting is usually the better choice, because the recipient may face the same limitation. If you only need to look at it yourself, a local decoder is quicker and changes nothing on disk.

Either way, no conversion is needed to prove the file is valid. A file that opens on an iPhone and not in a desktop browser is intact; the software is the constraint.

Feature detection and graceful fallback

Rather than guessing which browsers support which codecs, code can test. Creating an image element with a small HEIC data URI and checking whether it loads reveals what the current browser can do, and the same technique works for AVIF.

A fallback path is still needed for the case where the test fails. In practice that means a converted source, a download link, or a message telling the visitor why the image is unavailable and what they can do instead.

Keep test results out of long-term assumptions. A capability detected today may change with a browser update, in either direction, so detection at runtime is more reliable than a list of supported versions.

HEIC, AVIF and the HEIF family in browsers

AVIF shares the HEIF container with HEIC and swaps HEVC for AV1, which carries no royalty burden. That difference is a large part of why AVIF support arrived in browsers far more readily than HEIC support did.

Both formats can hold HDR and wide colour, and both can be more efficient than JPEG. The practical difference for the web has been licensing rather than capability.

It is worth remembering that a browser supporting one member of the HEIF family does not automatically support the others. Support is decided per codec, not per container.

How to check your own browser

Open the file directly. If the browser can display it, support is present; if it offers a download or shows an error, decoding is unavailable. Testing your own setup takes seconds and avoids relying on general claims, including the ones on this page.

A local viewer that decodes with WebAssembly is a useful cross-check, because it does not depend on the browser's built-in support at all. If the file renders there and not in the browser tab, the difference is the browser.

If you maintain a website, repeat the check across the browsers your audience actually uses rather than only the one you develop in. The failures are asymmetric: a site tested only in Safari can look broken in Chrome.