HEIC to WebP — Turn iPhone Photos into Web-Friendly Images Online, Balancing Size and Transparency

HEIC to WebP is meant for photos that are going onto a web page. HEIC is excellent at saving space on a phone, but most browsers do not recognise the container at all, so uploading an original iPhone shot straight to a site can leave visitors staring at an empty box. WebP, on the other hand, is supported across recent mainstream browsers: its lossy mode squeezes photos down, and it can carry a separate alpha channel, so one image no longer has to choose between small size and transparency. This page fully decodes the HEIC in the browser and re-encodes it as WebP with a quality slider you control — higher values keep more detail and produce larger files, and around zero point eight is usually a good starting point. Import several images at once, compare original and output sizes side by side in the batch list, and step through the preview with Previous and Next to check edges and gradients in the two panes. WebP is only the default; the dropdown switches to JPG or PNG at any time, and already-decoded images re-export automatically. Older Safari versions, legacy viewers and some print systems may still refuse WebP, so prepare a JPG fallback with a picture element when distributing to the public. Decoding tries the browser’s native capability first and falls back to a local WASM decoder, with nothing uploaded.

Import images

Drop HEIC or HEIF images here, or click to choose filesImport several at once, or press Ctrl+V to paste an image from the clipboardAVIF, JPG, PNG and WebP are accepted too · up to 40.00 MB per file · 30 files maxChoose images

Target format

Output format

All three formats reuse the same decoded pixels, so switching re-exports automatically — no need to import again.

WebP balances file size and transparency for the web. Very old Safari versions and legacy viewers may not open it.

Compression quality 88%

Higher values keep more detail and produce larger files. Around 0.85 suits photos; push it higher for screenshots.

Extra rotation

Some HEIC files store orientation as a container property and decode sideways. Correct it here if needed.

Filename suffix

Leave it empty to keep the original name; the extension is replaced with the output format.

Preview and export

Import an image to compare the original and converted result side by side or with a draggable split.

Batch list

0 / 0 Done

No images imported yet.

How to use

Drag HEIC or HEIF photos into the import area, or click Choose images to select several at once; Ctrl+V pastes a screenshot too. The tool reads the file header to identify the real container, so a wrong extension does not change the result.
Leave the target format on its default WebP, start with quality around zero point eight and look at the output size, then nudge it either way: push a large sky too hard and it bands, while text and icon edges need checking for softness.
Turn on the checkerboard to verify the edges of material with transparency. A few HEIC files disagree on the orientation property and decode sideways — correct those with Extra rotation, and the change re-exports automatically.
Use Previous and Next to compare each pair side by side, then download the current image or pack the batch into a ZIP. When shipping, pair the picture element with a JPG fallback for clients that still cannot read WebP.

Frequently asked questions

Why can I not put HEIC straight onto my website?

Because browsers generally do not recognise the container. HEIC is the ISO base media file format holding an HEVC intra image; Safari can read it on Apple platforms, while Chrome, Edge, Firefox and an ordinary image tag usually show a blank box or trigger a download. Even if a visitor’s phone opens it, your server, CDN, thumbnail service and content management system may not handle it. A WebP renders directly in every mainstream browser and usually costs less traffic than a JPG.

Is the WebP always smaller than the original HEIC?

Not always. The HEVC intra coding inside HEIC is very efficient, especially for large phone photos, so re-encoding to lossy WebP can occasionally make the file bigger. The clearest wins come from replacing PNGs or high-quality JPGs already on your site, and from large images with transparent backgrounds. The page lists before and after sizes with the percentage, so check the data before keeping a version instead of judging by the format name.

Does a transparent background survive?

It does. The WebP RIFF container can carry a separate alpha segment, so fully transparent areas and feathered semi-transparent edges are preserved, and the checkerboard confirms it. This is quite different from JPG, which has to composite transparency onto a solid colour. Bear in mind that if the HEIC original is an opaque camera photo, the output will not magically gain transparent pixels.

Is quality one the same as lossless WebP?

No. The web canvas offers only a lossy encoder plus a quality argument, and setting it to one still produces a very slightly lossy result. libwebp does have a separate lossless mode and near-lossless parameters, but browsers do not expose that layer to JavaScript and this tool does not ship a WASM encoder, so the button is not labelled lossless. Use the PNG page if you need genuinely lossless output.

What if someone cannot open the WebP I sent?

Very old Safari versions, some legacy office suites and print systems really do reject WebP, and Apple devices before iOS 14 and macOS Big Sur are the usual suspects. For a website, the safest approach is a picture element with a JPG alongside it, letting the browser choose. If you are sending the file directly through chat, email or an older system, switch the dropdown to JPG and export once more — the already-decoded images do not need importing again.

What is it

WebP comes from video coding: Google released it in 2010 based on the key-frame compression of VP8, predicting the current block from its neighbours and sending only the residual into a transform and Boolean arithmetic coding, so photos and gradients need fewer bits. Its RIFF container can hold lossy image data, separate alpha data, metadata and animation frames at once, so transparent edges are never forced onto a background colour the way they are with JPG. One boundary should be stated plainly: the browser canvas exposes only a lossy encoder plus a quality argument, and even setting quality to one is merely near-lossless — the true lossless mode and near-lossless parameters inside libwebp are not open to web pages, so this tool will not label its output lossless. On the HEIC side, HEVC intra coding is lossy too; conversion means one decode and one encode, a second round of loss that becomes essentially invisible above quality zero point eight. The wide gamut and ten-bit HDR that HEIC often carries are also mapped onto the canvas’s eight-bit sRGB during decoding, which can flatten the brightest highlights. The info line shows before and after sizes and the percentage, so let the numbers decide whether this version deserves to ship.

Origin & history

The timeline falls into three parts. The first begins in September 2010: Google had acquired the video coding company On2 Technologies the year before, taking ownership of VP8, and released WebP based on its intra coding, using a RIFF container to hold the compressed image data. The first version was lossy only; 2011 added an alpha-capable extension, and around 2012 came separate lossless coding, metadata and animation, while the open-source libwebp reference implementation was adopted by Chromium, Android and a great many server-side toolchains. The second part is the long rollout: Chrome supported it early, Firefox followed only in version 65 in 2019, and Safari completed the set with iOS 14 and macOS Big Sur in 2020, so picture elements and server-side content negotiation by request header were effectively mandatory, with two assets to maintain per page. The third part starts with HEVC being finalised in 2013 and HEIF published in 2015; in 2017 Apple made HEIC the default photo format in iOS 11, and hundreds of millions of devices began producing a container browsers could not read, while support across Windows, Android vendors and content management systems was uneven. The interesting part is that the key to the third section came from the ecosystem left by the first: canvas toBlob had long accepted WebP with a quality argument, so the encoding side was never the obstacle — HEIC decoding was. After 2018, open-source implementations such as libheif were compiled to WASM with Emscripten, and for the first time a web page could obtain the pixels of an HEVC intra image without uploading anything. Joining local decoding to local encoding removed the detour through a server between the camera roll and a live asset. One boundary is worth remembering: the web interface exposes only lossy coding, so even maximum quality is merely near-lossless, and libwebp’s lossless mode still needs a dedicated compiled build; any claim that a web page produced lossless WebP deserves a follow-up question. Meanwhile computational photography on phones has made a single file look more like a small program than a still picture; the more complex the container, the less dispensable local decoding becomes, and what the web page receives is always just that decoded eight-bit version.