What Happens to an iPhone HEIC Photo in a Browser Tool

You take a photo on an iPhone, drop it into a web tool, and one of three things happens. It works and the output is a different format. It works but the file you get back is bigger than the one you started with. Or the tool says it cannot read the file at all.

All three have the same cause, and understanding it takes about two minutes and saves a lot of guessing.

HEIC is not a kind of JPEG

Since iOS 11, the default capture format on iPhone has been HEIC. The container is HEIF, and the image data inside it is coded with HEVC, the same family of compression used for 4K video. That is genuinely better compression than JPEG: for most photographs a HEIC file is roughly half the size at comparable quality.

The cost is support. JPEG decoders are in everything, including every browser, going back decades. HEVC image decoding is not. No mainstream browser will hand a HEIC file to a canvas the way it hands over a JPEG or a PNG, so any browser-based tool that accepts HEIC has to decode it itself.

The file extension is not consulted

One practical detail worth knowing, because it explains behaviour that otherwise looks arbitrary.

Files here are identified by their first bytes, not their names. For formats built on the ISO base media container, which includes HEIC and AVIF, the identifying value is the brand code that sits at byte eight of the file. A file whose brand reads heic, heix, hevc, mif1 or one of a handful of relatives is treated as HEIC regardless of what it is called.

Two consequences follow. A photo someone renamed to .jpg because a website demanded a JPEG still decodes correctly, because the bytes never changed. And a file with a .heic extension that is actually something else fails immediately with a clear message rather than half-loading and producing garbage.

The decode is a conversion, and it is not free

Because the browser cannot decode HEVC still images, the file is converted to a JPEG in memory first, at high quality, and the result of that conversion is what enters the pipeline.

That is an honest lossy step and it is worth saying out loud. In practice you will not see it on an ordinary photograph: the quality setting used is high enough that the difference is below what a screen shows you. Where it can matter is on the two things JPEG has always been worst at, which are large areas of very smooth gradient and hard-edged graphic detail such as small text or a screenshot. If your HEIC is a photograph, ignore this. If it is a screen capture, export it from your phone as PNG instead and skip the conversion entirely.

Only the primary still image comes through. If the file is a Live Photo, the motion is in a separate video file that is not part of the image, and it is not carried into any of these tools.

Nothing here writes HEIC back out

This is the part that surprises people, and it is a deliberate choice rather than an omission.

The image tools output PNG, WebP, AVIF, and JPG. HEIC is an input format and not an output format. There is no browser API to encode HEVC stills, and shipping an encoder for it would mean a large download to produce a file that fewer programs can open than the alternatives.

So expect your exported file to be a different format from the one you brought in. That is not a bug, and it is usually what you wanted, since the reason people run an iPhone photo through a web tool is very often that something downstream refused to accept HEIC.

Why the output file is bigger

Here is the most common complaint, and it follows from everything above.

Your 2 MB HEIC becomes a 5 MB PNG, and it looks like the tool inflated your photo. It did not. PNG is lossless, so it stores every pixel exactly, and a photograph stored losslessly is simply large. HEIC was small because it was doing aggressive lossy compression on the way in.

You are not comparing a good file to a bad one. You are comparing two different jobs.

If output size matters, do not accept the PNG. Encode to WebP or AVIF instead, both of which are lossy formats designed for exactly this and both of which will land much closer to your original HEIC. Compare Formats will encode the same image as lossless PNG, as WebP at two quality levels, as AVIF, and as JPG in one pass and put the file sizes side by side, which turns the question from an argument into a number.

The megapixel ceiling

A recent iPhone can shoot 48 megapixels, which is around 8000 pixels on the long side.

Images are capped when they are decoded: 4096 pixels on the long side on a desktop machine, 1536 on a phone, 1024 on a device that reports itself as low on memory. A 48-megapixel capture is therefore scaled down before any tool touches it, and the tool will tell you it did.

This is not a limitation anyone enjoys. It exists because holding an uncompressed 48-megapixel image, plus a working copy, plus a model's input tensor, inside one browser tab is how a tab dies. A correct result at 4096 pixels is better than a crashed page at 8064.

If you need full resolution preserved, shoot at a lower capture setting, or do the resize on the phone before you start.

Metadata, which is the real reason to care

An iPhone HEIC carries a lot: GPS coordinates, the device model, capture settings, timestamps, and sometimes editing history.

The Metadata Remover strips those losslessly, rewriting the file container with the chosen blocks removed and copying the compressed image data through untouched. It works on JPEG, PNG, and WebP, which are the three container formats it can safely rewrite. HEIC is not one of them.

So the order is: convert first, then strip. Run your HEIC through any tool that produces a JPEG, PNG, or WebP, and run the metadata pass on that output. Doing it the other way round is not possible, and doing the strip before a later re-encode does not work either, because the encoder writes its own metadata into whatever it produces.

The short version

HEIC is a compact modern format that browsers cannot decode natively. It is converted on the way in, which costs a small amount of quality you will not see on a photograph. It is never written back out. Your exported file will be a different format and, if you take the lossless option, a larger one. And if privacy is why you are here, convert first and strip second.