HEIC to JPG Colors Look Different?

iPhone photos are usually shot in Display P3, a wider color gamut than the sRGB most JPGs and screens expect, so a naive HEIC-to-JPG conversion that just relabels the pixel bytes as sRGB instead of remapping them can shift colors — reds and greens especially can look oversaturated or "off." A converter that actually color-manages the conversion (remapping P3 values down into sRGB's smaller range, not just renaming the label) avoids this and produces colors that match what you saw on your iPhone. This is a real, documented problem — it shows up repeatedly in Apple Community and Adobe Community threads about HEIC exports looking wrong on other devices or in other apps. It is not random or a sign your photo is damaged; it's a specific, fixable color-space handling bug in the tool doing the conversion, not in the original file.

Display P3 is the color space iPhone cameras capture in by default (has been since the iPhone 7), and it covers a noticeably wider range of colors than sRGB, especially in saturated reds and greens. sRGB is the older, narrower standard that most JPG viewers, older software, and the web at large were built around and still assume by default. A color that exists in Display P3 but falls outside sRGB's smaller range cannot be represented as-is in an sRGB JPG — it has to be mapped to the nearest color sRGB can actually display. Done correctly, that remapping is a deliberate, visually-consistent compression of the color range, and the photo still looks essentially like the original. Skipped or done incorrectly, the same P3 numeric values just get reinterpreted as if they were already sRGB values, which pushes already-saturated colors even further, producing the oversaturated, "wrong" look forum posters describe.

Every properly saved HEIC photo carries an embedded ICC color profile that tells any reader "these pixel values are Display P3, not sRGB." A correct conversion tool reads that profile and uses it to remap each pixel's actual color into sRGB's range — this is standard, well-understood color management, not a pixeltools-specific technique. The failure mode that produces the washed-out or oversaturated look is different: some converters ignore the embedded profile and just copy the raw numeric pixel values into a JPG that's implicitly labeled sRGB, without doing any gamut remapping at all. The bytes are identical, but their meaning has silently changed — a red that was correctly moderate in Display P3 gets read as an even more intense red in sRGB, because the same numbers mean different actual colors in the two color spaces. That mismatch between the file's real color space and what's assumed when it's displayed is the root cause behind most of these forum reports.

Browsers handle this correctly by default when a page uses the standard HTML Canvas 2D API to do the conversion. A Canvas 2D context defaults to the sRGB color space unless a page explicitly asks for display-p3. When you draw a source image onto that canvas, the browser doesn't just copy raw bytes — it performs real, color-managed gamut mapping, honoring the source image's embedded color profile and converting its Display P3 values into the canvas's sRGB space correctly. This is exactly the mechanism a correct converter relies on: decode the HEIC into full-color pixel data, draw it onto a default (sRGB) canvas, and let the browser's own color management do the P3-to-sRGB conversion, rather than hand-rolling that math or skipping it. It's the same category of correct, standards-based color handling that a well-built desktop photo app performs — just running in the browser instead.

PixelTools' HEIC to JPG converter runs entirely in your browser: it decodes the HEIC file using a WebAssembly build of libheif, draws the decoded pixel data onto an HTML Canvas element, then exports the result through the browser's native JPEG encoder — no files are uploaded to a server. Because that Canvas defaults to sRGB and drawImage() honors the HEIC's embedded Display P3 profile during the draw, the P3-to-sRGB conversion happens as a real, color-managed gamut mapping rather than a naive byte relabel. That's not a claim of some proprietary color-matching benchmark — it's simply what the standard Canvas 2D drawing model does by design, and it's the behavior that avoids the specific oversaturation failure mode described in the forum threads this article is based on.

Not every "colors look wrong" report is a conversion bug — the viewing app on the receiving end matters too. Even a correctly converted, properly sRGB-tagged JPG can look off if it's opened in an app or displayed on a screen that isn't itself color-managed, because non-color-managed software can misinterpret or ignore a file's color profile regardless of how accurately it was written. This is a separate failure point from the conversion step, and it's why the same JPG can look correct in one app and slightly different in another. If your converted JPG looks right in your browser and in a color-managed app (like Preview on Mac or most modern browsers) but off somewhere else, the conversion likely wasn't the problem — check the second app's own color-management settings before assuming the file is bad.