Convert HEIC to JPG, plus PNG, WebP, and AVIF

Why some conversions are instant and others take a second

Browsers already know how to read JPG, PNG, WebP, AVIF, GIF, and BMP. Decoding those formats is built in, so there's nothing to download and conversion starts immediately. HEIC is the exception. Safari can decode it natively too, so on an iPhone or a Mac this tool skips any extra download entirely. Chrome and Firefox can't read HEIC on their own, so the first time you drop in a HEIC file, it quietly loads a small HEIC decoder (built on the open-source libheif project, roughly 2–3 MB) and runs it locally. It only loads once per visit, and only if you actually feed it a HEIC file. Someone converting WebP to JPG never downloads it at all.

AVIF output has the opposite problem. Every current browser can read AVIF through its canvas, but none of them can write it: there's no browser API that produces AVIF from a canvas, full stop. So choosing AVIF as your output format loads a separate, roughly 1 MB encoder the first time you use it, the same way the HEIC decoder does. Converting AVIF files to JPG, PNG, or WebP costs nothing extra since that's just decoding. In short: HEIC in and AVIF out are the two cases where the first file in a batch causes a brief pause. Everything else (JPG, PNG, WebP in any direction) is immediate.

Formats in, formats out

The format is identified by reading the actual bytes at the start of the file: the JPEG marker, the PNG signature, the RIFF/WEBP container, HEIC's ftyp box, not by trusting the file extension. That matters because iPhone exports and hand-renamed files lie about their own extension often enough that trusting it would misfire.

Two real limits worth knowing before you rely on this: GIF input only pulls the first frame, so an animated GIF comes out as one still image, not an animated WebP. And a HEIC from a Live Photo actually bundles more than one image inside its container (a primary photo plus auxiliary depth/motion data). This tool extracts the primary photo only and leaves the rest behind.

Resizing and hitting a target file size

You can drive quality directly with a slider (1–100, defaulting to 90 for JPG/WebP/AVIF), or switch to lossless for PNG output, which skips the quality question since PNG doesn't have one. Or you can type a target file size (say, 500 KB) and the tool searches for the highest quality that lands under it, testing at most six quality values along the way instead of scanning every number from 1 to 100. If quality 10, the lowest it will go, is still bigger than what you asked for, it says so rather than quietly handing you an oversized file. Some photos just can't get that small without falling apart.

Resize modes: a max dimension, a percentage, an exact width and height, or presets sized for common uses: Web (1920px), Email (1024px), Thumbnail (512px), each measured on the longer side. Aspect ratio holds for every mode except exact, and it never enlarges a photo past its original size. For a downscale bigger than 2×, it steps down in halves rather than squeezing the image in one pass, which keeps noticeably more detail than a single big resize would.

JPG has no transparency channel, so if your source has see-through pixels (PNG, WebP, or a HEIC with alpha), they get filled with a background color (white unless you pick another) before saving. And because every photo is rebuilt from scratch during conversion, the GPS location, camera model, and timestamp data that phones and cameras normally embed comes off automatically. That's a side effect of how re-encoding works, not a separate scrubbing step, and there's currently no option to keep it if you wanted to.

Running a batch

There's no per-batch cap: drop in one photo or a few thousand. Up to four photos convert at once, scaled to how many processor cores your device has, so a big batch keeps the page responsive instead of freezing it. Each file is only pulled into memory right before its turn and let go right after, so memory use tracks how many photos are converting at once, not the size of the whole batch: queuing 500 photos doesn't try to hold 500 decoded images at the same time.

On Chrome or Edge, "Save All" writes results straight into a folder you pick, since those browsers let a web page ask for write access to a folder. Firefox and Safari don't offer that, so there you get a ZIP download instead. Either way your originals are never touched or deleted. Every output is a new file sitting next to (or in a folder alongside) the source.