Skip to content

HEIC to JPG Converter

Drop HEIC / HEIF files or click to browse

Files are decoded with libheif WASM in your browser — never uploaded. First file triggers a one-time ~600 KB library download.

Output format

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

If you’ve ever needed to upload an iPhone photo to a website that rejected it, this is the tool. iOS HEIC photos are great on the device — half the size of JPEG at the same quality — but most websites and forms only accept JPG or PNG. This tool converts in your browser via libheif WASM (no upload, no server).

How decoding works

libheif is the reference HEIC/HEIF decoder, written in C++ and compiled to WebAssembly. heic2any wraps it with a friendlier API for the browser: pass a Blob, get back a JPG or PNG Blob. Decoding runs on the main thread (or a worker, depending on browser implementation) — entirely client-side, no network request after the initial library download.

The library is dynamic-imported on first interaction so it doesn’t bloat the initial page load. After the first conversion, the library is cached in the JS module registry for the rest of your session.

Example: converting an iPhone burst

A 5-photo burst from an iPhone produces 5 HEIC files, ~2 MB each. Drop them all on the tool, JPG at 92%, click. Five JPGs at ~1.8 MB each (or smaller — HEIC’s compression is excellent so the JPG output at quality-equivalent settings is often slightly bigger). Download each, attach to wherever you needed JPGs.

Example: single HEIC for a job application

A single iPhone photo (IMG_1234.HEIC, 1.8 MB). Drop, convert to JPG at 92%. Output: IMG_1234.jpg at ~1.6 MB. Upload to the form. Done.

When this tool isn’t the right answer

  • You have HEIC sequences with multiple frames you need separately. heic2any extracts the first frame by default. For all frames, you’d need a script that calls the underlying API with multiple: true.
  • You need EXIF preserved. Browser image-encoding paths strip most metadata. Use a desktop tool with explicit EXIF support.
  • You have hundreds of files. Browser memory is finite — converting 50+ HEICs in one batch may slow down or crash the tab. Use a desktop CLI (heif-convert from libheif-tools, sips on macOS, ImageMagick) for bulk workflows.

Common mistakes

Trying to convert non-HEIC files. The tool detects HEIC by MIME type (image/heic, image/heif) or filename extension (.heic, .heif). Anything else gets flagged as ‘not HEIC’ and skipped. If you have JPGs or PNGs that need format conversion or compression, see the format converter / compressor.

Picking PNG by default. PNG is lossless and produces 3-5× bigger files than JPG for photographic content. Pick JPG unless you specifically need lossless output.

Expecting metadata to round-trip. Browser image encoders drop most metadata. If location data or capture timestamps matter, use a desktop tool.

Waiting for the first conversion to be instant. It won’t be — the libheif WASM bundle takes ~1 second to download on a typical connection. Subsequent conversions are milliseconds.

Cross-checking sizes between iPhone, macOS, and Windows. A 1.8 MB photo on macOS shows as ~1.72 MB on Windows because macOS uses decimal MB and Windows uses binary “MB” under the same label. The MB-vs-MiB converter translates between the two.

What this tool does not do

It doesn’t upload anywhere. All decoding happens in your browser via libheif WASM.

It doesn’t convert non-HEIC formats. For JPEG ↔ PNG ↔ WebP ↔ AVIF, see the image format converter.

It doesn’t preserve full EXIF. Browser-side image encoding strips metadata. Desktop tools have better EXIF support.

It doesn’t batch-zip the output. One download per file — HEIC bursts are usually small enough that per-file download is simpler than zip handling.

It doesn’t handle Live Photo motion. The video portion lives in a separate MOV file that has to be processed with a video tool. After converting to JPEG, the image compressor and image resizer can further shrink the output before publishing.

Frequently asked questions

Why is HEIC even a thing?

Apple switched iPhone photos to HEIC in 2017 (iOS 11) because it stores roughly the same image quality as JPEG in half the bytes. The format itself (High Efficiency Image Container, derived from HEVC video) is technically excellent. The catch is interop: most non-Apple desktops, browsers, and websites still don't display HEIC natively, so you have to convert before sharing or uploading. Most modern Macs and Windows 11 (with the HEIF Image Extensions) can preview HEIC, but try uploading one to a job application form and you'll usually get rejected.

Why does the first conversion take longer than later ones?

Because the libheif WASM bundle (~600 KB plus heic2any wrapper) is loaded on first use, not at page load. This keeps the page itself fast for visitors who only read the docs without converting. After the first conversion the library is cached for the browser session and every subsequent file is decoded instantly. The trade-off: ~1 second one-time delay versus a faster initial paint and better SEO.

JPG or PNG?

Default JPG unless you specifically need PNG. JPG is what every photo workflow expects, supports the same lossy compression HEIC was designed around, and produces files of similar size to the original HEIC at quality 85-92. Pick PNG only if you need lossless output (no JPEG re-encoding artefacts) or if the photo has true transparency that PNG can preserve. Most camera HEICs have no alpha — JPG is fine.

Can it handle Live Photos / HEIC sequences?

It decodes the still image (the primary representation), not the video portion of a Live Photo. iPhone Live Photos are stored as an HEIC + an MOV sidecar; the HEIC contains the still frame the user sees as the 'photo' and that's what comes out. The motion data lives in the MOV file alongside it. heic2any handles HEIC sequences (multiple images packed in one file, e.g. burst mode) by extracting the first image; pass `multiple: true` to the underlying API for all frames if you need them.

Does it preserve EXIF metadata?

Most of it, no — heic2any decodes via libheif but the resulting Blob goes through the browser's image-encoding path which strips most metadata. GPS coordinates, device serial numbers, and other potentially sensitive fields don't survive. For users this is mostly a feature: HEICs from iPhones contain extensive metadata that you usually don't want bundled with a public-facing JPG. If you need EXIF preservation specifically, use a desktop tool like ImageMagick or Apple's own Image Capture.