When you share a photo from your iPhone and it quietly arrives as a JPEG on the other end, most people assume nothing of consequence happened. The image looks fine. It opened. Job done. But the conversion from HEIF (High Efficiency Image File Format, with the .heic file extension on Apple devices) to JPEG is not a neutral file-rename — it is a series of irreversible technical decisions, each one discarding something the original file contained.
Understanding what those decisions actually are matters whether you’re archiving family photos, sending work to a retoucher, or troubleshooting why an image that looked great on your iPhone looks slightly different everywhere else.
What HEIF Actually Contains That JPEG Cannot
HEIF stores image data using the HEVC (H.265) codec, which operates on a fundamentally different compression model than JPEG’s Discrete Cosine Transform. That difference is worth naming precisely: JPEG breaks each color channel into 8×8 pixel blocks, applies DCT to convert spatial information into frequency data, then quantizes those frequencies — meaning it deliberately discards the ones it considers less visible. HEIF/HEVC uses larger, more flexible prediction units and inter-frame techniques borrowed from video compression, which allows it to encode more detail at the same file size, or the same detail at a smaller file size.
But codec efficiency is only part of what separates the two formats. Three other things matter more for practical photography:
Bit depth. iPhone camera sensors capture in 10-bit HEIF by default on recent models. That means 1,024 possible values per color channel. JPEG is an 8-bit format: 256 values per channel. When you convert, 10-bit data gets mapped down to 8-bit, collapsing fine gradients — particularly visible in skies, skin tones, and any area with a slow tonal transition. The mapping is mathematically precise, but the range is permanently narrower.
Wide color (Display P3). iPhones shoot and display in the Display P3 color space, which covers a wider gamut than the sRGB color space JPEG assumes. A properly tagged HEIF file carries an embedded ICC profile describing P3. When converting to JPEG, what happens to that gamut depends entirely on what does the converting. If the conversion is gamut-aware, it maps P3 colors into sRGB as accurately as possible — meaning saturated reds, oranges, and greens that live outside sRGB get clipped or compressed toward duller equivalents. If the conversion is gamut-unaware and simply strips the profile, the raw numerical values get reinterpreted as sRGB, which shifts those same colors in a different, less predictable direction.
Auxiliary image data. HEIF is a container format. A single .heic file from an iPhone can hold a primary still image, a depth map, a portrait segmentation mask, a thumbnail, and — if you shot in Apple’s ProRAW variant — significantly more metadata about the capture. JPEG is not a container in the same sense; it holds one compressed image and its EXIF data. The depth map and segmentation mask go away. Whether you ever intended to use them is beside the point — the conversion decision is permanent.
What Happens to Metadata
EXIF data — shutter speed, aperture, ISO, GPS coordinates, device model, timestamp — typically survives the conversion intact when the conversion is handled by the operating system or a competent tool. Where things get murkier is XMP and IPTC metadata. If you’ve added captions, keywords, or copyright notices in an app that writes to the HEIF container, some conversion paths preserve them and some silently drop them. There is no universal guarantee.
Apple’s own “Automatic” transfer setting — found under Settings > Photos > Transfer to Mac or PC — converts to JPEG on the fly during AirDrop or cable transfer to non-Apple systems while keeping the HEIF original on the device. That is one of the cleaner approaches precisely because it happens late in the pipeline, just before handoff, and the source file is never touched. The practical mechanics of triggering that behavior, and the alternative routes, are covered in detail in How to Convert HEIC to JPEG on iPhone Without Third-Party Apps.
The Compression Decision Is Made Twice
Here is a detail that often gets overlooked: converting HEIF to JPEG does not simply move existing compressed data into a new container. The image is decoded — fully decompressed back to a pixel grid — and then re-encoded as a JPEG from scratch. That means the JPEG encoder applies its own quantization step fresh, at whatever quality setting the converting tool uses.
If a tool defaults to JPEG quality 85, that is a separate and additional lossy pass on top of whatever quality the HEIF was originally captured at. Higher-quality JPEG settings (90–95) minimize the additional damage; quality settings below 80 will introduce visible blocking artifacts in areas with texture. You cannot recover the original HEVC-compressed data from the JPEG — the quantization step in JPEG encoding permanently discards frequency information, and it does so every single time you re-save.
This also means that the file size after conversion is not predictable purely from the original HEIF size. JPEG at high quality on a detailed photo can actually be larger than the HEIF source, because HEVC’s compression efficiency genuinely exceeds what JPEG’s DCT achieves on the same content. The widespread assumption that HEIF files are always smaller reverses for some image types at matched quality levels.
When the Conversion Is Invisible and When It Is Not
For many use cases — sharing via Messages, posting to social platforms, printing — the difference between a well-converted JPEG and the original HEIF is not likely to be visible at normal viewing sizes. The compression differences and the bit-depth reduction don’t announce themselves in a thumbnail or a 1080-pixel-wide web image.
Where they become apparent:
- Heavily edited photos where you’re pushing shadows or highlights in post-processing — 10-bit data gives editors more room; 8-bit clips sooner
- Large prints where gradient banding in skies becomes visible
- Any workflow that involves further compression, like uploading to a platform that will re-encode the image; each generation of lossy compression stacks on the previous one
- Color-critical work where P3 saturation in specific hues matters to the final output
For deeper context on how that stacking affects social platform exports specifically, our article on what compression tradeoffs happen when you export for social media walks through the mechanism in more detail.
What to Do Before Converting
If you’re converting a batch of HEIF files and quality matters, a few things are worth deciding before you run the conversion:
- Set your JPEG quality explicitly. Don’t rely on whatever default a tool picks. Quality 90–95 is a reasonable floor for archival use; quality 80 is passable for web delivery but not for files you plan to edit further.
- Verify the color profile handling. Check whether the tool you’re using converts P3 to sRGB with a proper gamut mapping or simply strips the embedded profile. The former preserves relative color accuracy; the latter can shift saturated colors unpredictably.
- Keep the originals. HEIF to JPEG is irreversible — you cannot reconstruct the depth data, the 10-bit range, or the P3 gamut from the JPEG. Archive the
.heicfiles separately before converting, especially if these are photos you care about long-term. - Convert as late as possible. If you’re editing, edit the HEIF (or export to a 16-bit TIFF for intermediate steps) and only output to JPEG at the final delivery stage. Running edits on a JPEG and then saving again re-applies quantization.
- Check EXIF and any embedded metadata on a sample file after conversion to confirm your tool isn’t silently dropping location data, timestamps, or any custom tags you rely on.
The format question — whether to keep shooting HEIF at all, or whether the tradeoffs favor switching — is a separate decision covered in our HEIF vs. JPEG comparison. But if you’re converting existing HEIF files, the specifics above are what actually change in the file — not abstractions, but the exact data the format was holding.