Convert HEIF to WebP

Publishing platforms validate uploads against a list, and HEIF is seldom on it. That looks arbitrary until you consider what the platform has to do next: generate a thumbnail, produce three responsive sizes, and show you a preview in the editor. It cannot reliably do any of those with a format whose browser support is partial, so the safest thing it can do is decline the file.

The consequence is that the conversion is your job rather than the platform's, and doing it before upload is better than after. You control the dimensions and the quality; the platform's automatic re-encoder, if it has one, is working from whatever you handed it.

Google published WebP in 2010 and it is now standardised as RFC 9649. What makes it the default for this job is not compression cleverness but coverage: it is one of the few image formats on this site whose browser support is recorded as complete rather than modern or partial, so a single file works for every visitor without a fallback.

It also brings the two things a delivery format needs and JPEG lacks — an alpha channel and better compression at the same visible quality. For a page that has to load on a phone over a slow connection, those are the two levers that matter, and WebP has both without asking anybody to negotiate content types.

Quality defaults to 82 on a scale of 1 to 100. For photographs on a web page that is a good place to sit: detail survives at the size a browser will actually display, and the file is a fraction of what a lossless copy would cost. Dropping to the sixties buys real bytes and starts to show around edges and in flat areas.

Remember that this is the second compression the picture has been through. The camera compressed it into HEIF, and this compresses what came out of that. One extra pass at 82 is not something a visitor will spot, but it is a reason to convert from the HEIF original each time rather than converting a WebP again later.

WebP cannot describe an image larger than 16,383 pixels on a side. That is a property of the format, not of this converter, and no setting works around it. A twelve or forty-eight megapixel photograph is far below it in both directions, so for normal pictures the limit never comes up.

What does come up is a panorama. Phone panorama modes stitch a very wide, short image, and those routinely exceed sixteen thousand pixels across. For one of those, set a maximum width before converting — which you almost certainly wanted to do anyway, since no web page displays a picture at that width.

The maximum-width field is the most valuable control on this page for a web use. Reducing a 4,032-pixel photograph to 1,600 pixels cuts the data the encoder is given to roughly a sixth before compression starts, and 1,600 is already generous for a content image on a desktop layout.

Serving a full-resolution photograph and letting the browser scale it down is the commonest page-weight mistake there is: the visitor pays for every one of those pixels and sees perhaps a fifth of them. If you need several sizes for a responsive set, convert the HEIF several times at different widths rather than resizing the WebP afterwards.

Both formats have an alpha channel, so a picture with a cleared background arrives with it intact and can sit on a coloured section of a page without a white box around it.

Both formats also support animation, and that part does not cross. The decoder takes the primary image out of the HEIF container and the encoder writes a single still frame, so a multi-image HEIF becomes one picture. If the source is genuinely a sequence you want to keep moving, this is not the pair for it.

The WebP written here contains no EXIF and no XMP. Nothing was filtered out; the conversion decodes the picture to raw pixels and re-encodes it, and metadata has no route across that step.

On a page about publishing, that is the most useful thing on it. A photograph taken on a phone is routinely stamped with latitude and longitude accurate to a street address, and a marketplace listing or a blog post carrying that publishes where the photographer lives. Several large platforms strip it on upload and several do not; converting first means you are not relying on which kind you are dealing with.

AVIF compresses the same picture smaller at the same visible quality, and its browser support is newer than WebP's rather than universal. That is the whole comparison, and it decides itself on how your site serves images.

If you upload one file and it is served to everyone, WebP is the answer — no negotiation, no fallback, nothing to test. If your delivery layer can offer AVIF to browsers that announce it and WebP to the rest, then AVIF is worth the extra step and there is a separate page for that conversion. Choosing AVIF as your single format because it is newer is how a visitor gets a broken image.

Both the HEIF decoder and the WebP encoder run inside the browser tab, on your own processor. There is no upload, no queue and no account, and the file never exists on anybody's server — which for unpublished product shots and photographs of people who have not agreed to anything yet is the difference that matters.

The free tier takes up to 100 MB per file, which no phone photograph approaches. A whole folder converts in one pass with a progress row each, and once two files are done an "all as ZIP" button appears, so preparing thirty images for a gallery is one download rather than thirty.

Keep the HEIF. It is the highest-quality copy you have, it is the smallest one you have, and every future size or format you need should be made from it rather than from the WebP you published.

There is also no way back: this site can read HEIF and cannot write it, because the encoder that would be needed is under a licence a static site cannot satisfy. So the WebP is a derivative and the HEIF is the original, and it is worth filing them that way rather than deleting the one that cannot be recreated.

WebP is unusual among delivery formats in having two distinct modes: a lossy one built on video-style compression, and a lossless one closer in spirit to PNG. The registry records the format as capable of lossless, and it is worth knowing which of the two you are getting.

This conversion writes the lossy mode, at the quality figure you set. For a photograph that is the right call by a wide margin — lossless WebP of a camera image is several times the size and recovers nothing, since the HEIF discarded what it discarded before you arrived. If you specifically need a lossless copy of a HEIF, PNG is the honest way to ask for it.

Most content systems re-encode what you give them. They generate thumbnails, produce a responsive set, and frequently compress the original again with settings you cannot see. That means your WebP is an input to another encoder rather than the file a visitor downloads.

It is an argument for converting at the right dimensions and a generous quality rather than squeezing the file yourself. A picture already compressed hard at quality 55 and then re-encoded by the platform accumulates both sets of artefacts; one at 82 gives the platform something clean to work from. If your system stores the upload untouched, you have full control and the numbers on this page are the ones that ship.