iPhone HEIC photo bulk JPEG/PNG conversion tool | ZeroTools

This tool is dedicated to decoding and re-encoding HEIF (High Efficiency Image File Format) and HEIC images—standard formats on Apple iOS devices—into widely supported JPEG or PNG formats for web browsers and legacy operating systems.

HEIC is not merely a single image format; it is a container format packaged under the ISO Base Media File Format (ISOBMFF) that applies High Efficiency Video Coding (HEVC / H.265) compression to still images.

To handle these files as displayable pixel data, the complex compressed data stream must be parsed and decompressed into bitmap data in memory.

Internally, files dropped by the user are immediately read as binary data (Blobs) via the File API. In Windows environments and certain web browsers, .heic files are frequently recognized with an empty MIME type string.

To stabilize handoff to downstream decoding modules, the system internally reconstructs the buffer with an explicit image/heic type.

The tool provides two output formats: JPEG (image/jpeg), widely used for photographs, and PNG (image/png), which losslessly compresses decoded pixels.

Converting to PNG does not recreate the original pre-decoded HEIC data. The conversion pipeline strictly operates as a one-way mechanism that extracts primary still image pixel data from the source HEIC container and passes the stream to the user-selected format encoder.

When selecting JPEG as the output format, you can adjust output encoding quality from 0.5 to 1.0 (displayed as 50% to 100% in the UI) using the control slider.

The default setting is 85%, which balances visual quality for photographs with file size reduction.

JPEG uses lossy compression algorithms. After the original HEIC image is decoded to raw pixels, it is passed to the JPEG encoder's Discrete Cosine Transform (DCT) module, where irreversible quantization discards high-frequency data.

Lowering the quality setting coarsens quantization step intervals. While this significantly reduces file size, it increases visible artifacts such as block noise along 8x8 pixel boundaries and mosquito noise around high-contrast edges.

In the internal pipeline, this quality setting acts as an encoder parameter passed to the WebAssembly-based heic2any decoder or the browser's native HTMLCanvasElement.toBlob() fallback API rather than serving as a direct compression ratio.

Because HEIC and JPEG utilize different compression architectures and encoders, identical file sizes or compression ratios cannot be guaranteed, and a converted JPEG may sometimes be larger than the original HEIC file.

Actual size differences depend on image content and quality settings, so compare file sizes and visual previews before saving.

When the output format is set to PNG (Portable Network Graphics), pixel data decoded from HEIC is re-encoded using lossless compression based on the Deflate algorithm.

PNG conversion saves decoded pixels losslessly, but this does not mean original HEIC attributes such as color spaces or extended bit depths are retained in their initial state.

Lossless compression applies only to writing decoded pixel data into the PNG container. Typical photo captures usually undergo lossy HEVC compression in camera hardware, and minor quantization errors can occur during color space mapping during in-browser decoding.

Consequently, converting to PNG cannot restore detail or capture-time fidelity already discarded by earlier lossy compression.

When choosing formats, JPEG is suitable for typical landscapes, portraits, mobile camera roll storage backups, and blogs where minimizing data transfer and storage footprint is paramount.

Conversely, PNG is preferable for screenshots with crisp text, schematics, or images intended for further editing in software like Photoshop where repeated JPEG recompression artifacts should be avoided.

Note that saving complex photographs as PNG can increase file sizes several-fold compared to original HEIC files, sometimes reaching tens of megabytes.

This tool features a client-side batch queue designed to process dozens of HEIC files efficiently for everyday photo organization.

Images dropped into the upload area or selected via the file dialog do not start converting immediately; they are listed with a "Waiting" status, retaining unique IDs, file names, and byte sizes in memory.

When you click "Perform batch conversion", the system processes the queued items sequentially using an asynchronous loop. A key characteristic of this architecture is that intensive decoding executes entirely within your client browser memory.

No image upload or download requests are made to external servers or cloud APIs for conversion processing. This client-side processing isolates your private photos and sensitive images from transmission to conversion servers during decoding.

Files that finish converting update to "Complete", generating temporary Object URLs in browser memory for previewing and downloading.

When using "Save converted files all at once", the tool issues individual download requests spaced approximately 250 milliseconds apart as an implementation interval, though this does not guarantee prevention of browser spam or download blocks.

Depending on browser configurations, multiple automatic downloads may still require confirmation or get blocked, in which case individual row download buttons should be used.

Already completed items are skipped upon re-running, and changing settings retains previous outputs; to reconvert under new settings, remove and re-add the original images.

For both individual and batch saving, each row selects its saved file extension directly from its own convertedBlob.type (exact image/png maps to .png, otherwise defaulting to .jpg) rather than the current UI format, leaving the actual converted Blob intact.

This MIME type is handled purely as metadata without byte authenticity verification or format sniffing, so missing or unexpected values retain the legacy .jpg fallback.

Additionally, each download uses an independent URL revoked via a scheduled 1000ms callback, leaving preview URLs unaffected without modifying decoders or unmount lifecycles.

HEIC files captured on modern smartphones, particularly iPhones, contain rich metadata structures beyond standard two-dimensional pixel arrays.

When converting files in the browser, be aware of technical limitations where certain metadata or specialized image structures may be omitted or altered.

First, Exif (Exchangeable Image File Format) metadata—including GPS coordinates, timestamps, camera lens models, aperture (F-number), and shutter speeds—is not guaranteed to carry over to target JPEG or PNG files through current browser WebAssembly decoding pipelines or Canvas re-encoding.

In most cases, converted files will not retain original Exif headers.

Second, Live Photos combine a still image with an accompanying video file, but this tool only converts the primary still photo. It cannot package or link corresponding video or audio data into the converted image.

Similarly, continuous HEIF burst sequences and secondary auxiliary data such as portrait depth maps used for background blurring are not retained.

Finally, for images captured in HDR (High Dynamic Range) or wide color gamuts such as Display P3, color profiles and dynamic range may not be preserved depending on the decoder, browser, and output format combination.

This can result in shifts in brightness or color balance compared to the original image. Always inspect converted outputs against source files in compatible viewers.

In-browser HEIC decoding performance depends heavily on operating system versions, browser implementations, and available physical memory (RAM).

Unexpected errors can occasionally interrupt conversion. To maximize conversion success across client environments, the tool incorporates a multi-tier fallback mechanism in JavaScript.

The pipeline first attempts single-image decoding using the WebAssembly-based heic2any module with explicit MIME type enforcement.

If this initial attempt fails, a second-tier fallback retries decoding by passing the raw File object directly in the background.

If parsing still fails, a third-tier fallback switches to browser-native createImageBitmap decoding and generates Blobs via Canvas rendering.

If all fallback attempts fail and a red "Error" badge appears, several underlying causes are possible. One potential factor is device memory exhaustion (Out of Memory).

Processing very large HEIC images or batches of large files can exceed browser tab memory allocations, causing the process to terminate.

If this occurs, reload the browser tab to free allocated memory and retry using smaller batches of 3 to 5 files.

If error messages indicate corrupt file structures, the file may utilize an unsupported proprietary container (such as burst sequences) or the binary data may have been corrupted during transfer.

For files that fail decoding repeatedly, consider using device transfer settings that export compatible formats, or export directly to JPEG from desktop photo applications.