Why HEIC Images Are Not Fully Compatible on the Web

Quick answer

HEIC is good for storing iPhone photos, but it is still a poor default for publishing images on the open web. The format saves space, preserves good visual quality, and works smoothly inside modern Apple software. The problem starts when the same file has to pass through a browser, upload form, CMS, email client, Windows device, Android device, image CDN, or social scheduling tool.

For a public website, convert HEIC before publishing. Use WebP or AVIF for web delivery, keep JPEG as the compatibility fallback, and use PNG only when a form asks for it or when you need a lossless editing copy. Keep the original HEIC if you want the space-saving iPhone master.

This is not because HEIC is a bad image format. It is because website images need broad decoder support, predictable MIME handling, thumbnail generation, fallback behavior, and simple server processing. HEIC is still weak on several of those operational points.

HEIF and HEIC are not exactly the same thing

The first detail most articles skip: HEIF and HEIC are related, but not identical.

HEIF means High Efficiency Image File Format. It is a container. A container can hold image data, thumbnails, sequences, metadata, depth information, and other supporting data. HEIC is the common iPhone photo flavor: a HEIF file whose image data is encoded with HEVC, also known as H.265.

That distinction matters in real workflows. A system may understand the HEIF container but still need the HEVC decoder to read a typical .heic photo. Microsoft support guidance reflects this split: Windows users working with Apple-style HEIF/HEVC media may need both HEIF and HEVC components before Photos can use the files.

In plain English:

The web compatibility issue is usually not "the pixels are bad." The issue is the receiving software does not have the right container and codec path.

Why iPhones use HEIC

Apple introduced HEIF and HEVC support with iOS 11 and macOS High Sierra. Apple Support describes the practical reason clearly: HEIF and HEVC offer better compression than JPEG and H.264 while preserving similar visual quality, so they use less storage on the device and in iCloud Photos.

That tradeoff is sensible for a phone camera. A person may take thousands of photos, keep them for years, and view them mostly in Photos, Messages, AirDrop, iCloud, Preview, or other Apple-aware apps. In that world, HEIC is mostly invisible. The photo looks normal and uses less storage.

Apple also gives users a compatibility switch. On iPhone or iPad, Camera > Formats > Most Compatible makes new photos use JPEG instead of HEIF. High Efficiency switches back to HEIF/HEVC. Apple also notes that when sharing through methods such as AirDrop, Messages, or email, a device may automatically send a more compatible version when the receiver does not support the newer formats.

The word "may" is doing work there. Automatic conversion helps, but it does not cover every web upload path. If you choose a file from Files, export originals from iCloud, drag a raw .heic into a CMS, or upload from a desktop folder, the website may receive the original HEIC file.

Browser support is the real web problem

Websites do not just need "some device somewhere" to open the image. They need a visitor's browser to decode the image in an <img> tag, CSS background, social preview, CMS preview, search preview, image CDN, and sometimes an email client or app webview.

MDN's image format guide lists the common web image formats: AVIF, GIF, JPEG, PNG, SVG, and WebP. HEIC is not part of that common cross-browser set. Safari 17 added HEIC support in Safari, Safari View Controller, and WKWebView, which is useful for Apple-first importing and editing workflows. But a Safari feature does not automatically make a format safe for Chrome, Firefox, Edge, Android, Windows, embedded browsers, or all app webviews.

That is the subtle point. "Safari supports HEIC" and "HEIC is safe for the public web" are different claims.

For a public image URL, use formats that browsers and tools expect. WebP, AVIF, and JPEG fallbacks are less exciting than HEIC, but they keep the page from showing broken-image icons.

Safari 17 support helps, but it does not remove the need for fallbacks

WebKit announced HEIC support for Safari 17, Safari View Controller, and WKWebView. Apple Developer's WWDC23 media-format session also framed HEIC as useful for handling photos uploaded from iPhone without conversion, especially in Apple web and app-view contexts.

That is a real improvement. It means a web app used by people on Apple devices can import, preview, and edit iPhone photos more directly than before.

But Apple also said HEIC is not widely supported on other platforms and should probably be used as an alternative format. The same session recommends using the <picture> element so browsers can choose a format they support.

For a controlled Apple-heavy app, you might test a pattern like this:

<picture>
  <source srcset="/photos/hero.heic" type="image/heic" />
  <source srcset="/photos/hero.avif" type="image/avif" />
  <source srcset="/photos/hero.webp" type="image/webp" />
  <img src="/photos/hero.jpg" width="1200" height="800" alt="Product photo" />
</picture>

For most public sites, I would flip the mental model: start with AVIF or WebP, keep JPEG as the fallback, and store HEIC only as the original upload or internal master. Public pages should not depend on HEIC being available.

Where HEIC breaks in real web workflows

HEIC failures rarely look dramatic. They usually look boring and confusing:

• The upload button accepts the file, but the preview stays blank.
• The server rejects it because image/heic is not in the allowed MIME list.
• The browser reports an empty or unexpected file.type.
• The CMS stores the original but cannot create thumbnails.
• The image optimization plugin skips it.
• The CDN cannot resize it.
• The social share preview has no image.
• The recipient on Windows sees an attachment they cannot open.
• The help desk gets a "your photo is broken" ticket with no obvious cause.

That is why HEIC feels unreliable even when it works on your own iPhone. Web publishing is a chain. The file must survive file picker detection, client preview, upload validation, server decoding, derivative generation, CDN delivery, browser rendering, and sometimes search/social previews. One unsupported link is enough.

Windows support is not the same as browser support

Windows can work with HEIF/HEVC files in some situations, especially with the right Microsoft Store extensions or app support. Microsoft says Photos may need HEIF and HEVC extensions before it can use those files. Microsoft also notes that OneDrive can preview HEIF and HEVC files on the web, while downloaded files on Windows may still need a codec to open locally.

That does not mean a Windows visitor's browser can render your .heic image URL. OS preview support, OneDrive preview support, Photos app support, and browser image decoding are separate things.

This is a common developer trap:

1. A Windows machine opens the HEIC file in Photos after extensions are installed.
2. The developer assumes the file is "supported."
3. The same file fails as a normal website image for another user.

For web delivery, test in the target browsers, not just in the operating system preview app.

Why upload forms reject HEIC

Many upload forms were written when the practical file list was JPEG, PNG, and maybe WebP. Their checks often look like this:

• Extension allowlist: .jpg, .jpeg, .png, .webp.
• MIME allowlist: image/jpeg, image/png, image/webp.
• Server image library: expects JPEG/PNG/WebP/AVIF decoders.
• Thumbnail job: calls a library that was not built with HEIC support.
• File-size rule: assumes the converted output will be JPEG.

HEIC can fail any of those checks. Even if the frontend accepts image/*, the server may reject it. Even if the server stores it, the thumbnail generator may fail. Even if the thumbnail generator works, the final public URL may not render in all browsers.

If you run a site that accepts user-uploaded photos, the safest workflow is:

1. Accept HEIC as an input format if your audience uploads from iPhone.
2. Decode it on the client or server.
3. Store the original if you need it.
4. Generate public delivery files as WebP/AVIF plus JPEG fallback.
5. Show users a clear message when conversion fails.

Do not serve the raw HEIC as the only public image.

What to convert HEIC into

The best output depends on where the photo is going.

JPG is the compatibility fix. WebP is usually the practical web-delivery fix. AVIF is useful when you can generate and test fallbacks. PNG is for exact pixels or strict form requirements, not ordinary photos.

HEIC versus AVIF for the web

HEIC and AVIF are easy to confuse because both are modern and both can live in HEIF-family containers. The difference for a website owner is adoption.

AVIF is listed by MDN as a web image format supported in Chrome, Edge, Firefox, Opera, and Safari. Chrome's Lighthouse guidance encourages AVIF and WebP as modern image formats because they can reduce transfer size compared with older JPEG and PNG. Google's WebP documentation also describes WebP as natively supported in major browsers and broadly useful for webmasters.

HEIC does not have that same cross-browser story. It can be excellent in Apple workflows, but the public web rewards formats that render everywhere or degrade cleanly.

Use this rule:

• HEIC for original iPhone storage.
• WebP for the everyday website default.
• AVIF for pages where byte savings justify the pipeline.
• JPEG for fallbacks and non-web compatibility.
• PNG for exact graphics and strict upload requirements.

Metadata and privacy during conversion

HEIC photos can carry the same kinds of sensitive metadata people worry about in JPEGs: GPS coordinates, capture time, device model, lens details, and software history. Some converters preserve metadata. Some strip it. Some preserve only part of it.

PhotoTools' converter decodes the HEIC pixels and re-exports through the browser canvas pipeline. In this project, HEIC files are detected by MIME type or .heic/.heif extension, decoded with heic2any into PNG frame blobs, drawn through createImageBitmap and OffscreenCanvas, then exported with convertToBlob() as JPG, PNG, WebP, or AVIF. That kind of canvas re-encoding is useful when you want a clean delivery file, but you should still verify the output when GPS privacy matters.

If you need to keep metadata for archiving, keep the original HEIC. If you need to remove metadata for sharing, check the converted file before sending it.

How PhotoTools handles HEIC

PhotoTools treats HEIC as an input format, not as the best public output. That is the right shape for most web workflows.

When you drop a HEIC or HEIF file into the converter, the browser-side code recognizes it by MIME type or extension. Multi-frame HEIC files are expanded into individual frame cards. Each frame can then be exported to JPG, PNG, WebP, or AVIF. The source photo does not need to be uploaded to a conversion server.

This is useful for:

• iPhone photos that need to open on Windows.
• Web forms that reject HEIC.
• CMS uploads that need JPEG or WebP.
• Passport or application photos where the portal lists accepted formats.
• Product photos that should become WebP before publishing.
• Private photos where you do not want to send originals to a third-party server.

For ordinary sharing, choose JPG. For web publishing, choose WebP or AVIF with fallbacks. For a form that explicitly says PNG, choose PNG.

A practical checklist before publishing an iPhone photo

Use this checklist when a photo starts as HEIC:

1. Check the destination's accepted file types.
2. If it is a public website, do not publish the raw HEIC as the only source.
3. Convert to WebP or AVIF for delivery if your site supports those formats.
4. Keep a JPEG fallback for older browsers, email, and strict upload systems.
5. Use PNG only when exact pixels or a form requirement justifies the larger file.
6. Resize the photo to the largest size it will actually display.
7. Check whether metadata should be kept or removed.
8. Test the final page in more than Safari.

The short version: HEIC is a good capture and storage format. It is not yet a dependable universal web delivery format. Treat it as the original, then export the version your audience and pipeline can actually open.

Technical sources checked

This guide was reviewed against Apple Support's HEIF/HEVC guidance, WebKit's Safari 17 HEIC announcement, Apple Developer's media formats for the web session, MDN's image format guide, Microsoft's Photos HEIF/HEVC extension guidance, Microsoft's OneDrive HEIF/HEVC notes, Chrome Lighthouse image-format guidance, and Google's WebP documentation.