HEIC to WebP Converter

Only Safari can decode HEIC in the browser

This is the constraint that governs everything else on this page. Safari on macOS and iOS decodes HEIC natively because the Apple system frameworks underneath it already do. Chrome, Firefox and Edge ship no HEIC decoder on any operating system, largely because of the patent licensing attached to the HEVC codec inside the container.

No web page can work around that with a flag. Tools claiming otherwise are either uploading your photos to a server that has the codec installed, or shipping a multi megabyte WebAssembly decoder with its own colour management quirks. This tool does neither. It attempts the real decode and, if the browser refuses, tells you exactly why rather than handing back a blank image. Safari 14 and later can also encode WebP, so both halves of the conversion live in the same place.

When you should convert HEIC to WebP

WebP is the right target when the photo is heading for the web or for any modern software that will not read HEIC. It keeps the size advantage that made HEIC attractive in the first place, so a folder of holiday photos does not suddenly become a hundred megabytes on disk.

It is the wrong target when the destination is deliberately conservative. Print shops, older desktop editors and some corporate document systems still want JPG and nothing else, and an archive you expect to open in twenty years is better stored losslessly.

• Convert to WebP when the photos are going onto a website, a blog or a modern content management system.
• Convert to WebP when you want the storage saving of HEIC without the compatibility problem.
• Convert to WebP when transparency matters, since WebP carries a full alpha channel.
• Choose JPG instead when a print service, an email client or older software is the destination.
• Choose PNG instead when the photo will be edited repeatedly and generation loss matters.

Choosing the WebP quality setting

The slider maps onto the encoder quality factor from 20 up to 100. WebP degrades by blurring rather than by the blocking that JPEG produces, which most people find less objectionable at the same nominal number, so you can usually go a little lower than you would with JPEG.

For photographs, 80 is a sensible default and 75 is often indistinguishable while saving a further slice of the file. Push to 90 for images that will be viewed large or on a high density display. Setting 100 does not enable lossless mode, it simply spends a lot of bytes on a lossy encode, so it is rarely worth choosing.

Remember that the source has already been compressed once by the phone. Every lossy re encode compounds slightly, which is another reason to avoid dropping below about 70 on a photo that started life as HEIC.

How this HEIC to WebP converter works

Three browser primitives do all of the work. The File API reads the bytes you selected, the system image decoder Safari exposes turns the HEIC into pixels, and a canvas re encodes those pixels as WebP through the toBlob method with your chosen quality factor.

Because that whole chain runs on your machine, the camera roll cannot leak. There is no upload request to intercept, no temporary copy on someone else's disk and no retention policy to trust. Photographs are among the most personal files anyone converts, which makes that guarantee matter more here than in most places.

It also removes the caps a hosted service needs to impose. No queue, no daily limit and no file size ceiling beyond the memory your own device can spare, since the compute is yours rather than rented.

Converting a whole camera roll at once

Drop in as many photos as you like and this HEIC to WebP converter decodes and re encodes every one with the same quality setting. Each result is listed with its original size, its new size and the change between them, so an unusual file is easy to spot before you download anything.

Processing runs one file after another rather than in parallel. Encoding several twelve megapixel images at once competes for the same memory and triggers garbage collection pauses that cost more than the concurrency saves.

On an iPhone, memory is the real limit. A tab that reloads part way through a large batch is running out of room rather than hitting a bug, and splitting the work into groups of ten fixes it. Searching for a heic to webp online service usually leads to something that would have uploaded those iphone heic photos over a mobile connection instead, which is slower and less private.