From Phone Camera to Web Page: The Shortest Path That Does Not Waste Quality

July 29, 2026 · WebP.now Editorial · Mobile Workflows

An enormous share of web imagery now originates on a phone. Product photos for a small shop, article images for a blog, listing photos for a rental, progress shots for a client update — captured on a phone, destined for a web page.

The path between those two points usually involves more lossy re-encodes than it needs to, and each one costs a little quality that nothing recovers.

What your phone actually captures

iPhones have shot HEIC by default since iOS 11, and many Android devices now do the same. HEIC is genuinely excellent at what it does: roughly half the size of an equivalent JPEG, with 10-bit colour, HDR and depth information. It is a superb capture format.

It is also useless on the web. No browser renders HEIC, and given HEVC licensing, none is likely to. So it has to be converted — the only question is how many times.

The direct route

HEIC straight to WebP. One decode, one encode, done. Both formats are lossy so a small amount of generational loss is unavoidable, but at quality 80-90 it is not visible, and you have gone from a format no browser displays to one every browser displays without an intermediate step.

What you lose in the process is HEIC's capture extras — Live Photo motion, depth maps, 10-bit HDR colour. WebP has no concept of any of those. You get the main still image, which is what a web page wanted anyway.

Detour 1: routing through JPG

The common path is HEIC to JPG (because that is what people know how to do) and then JPG to WebP later when someone notices the page is slow. That is two lossy encodes instead of one, and the first one was at whatever quality the tool defaulted to.

If you already have JPGs and no longer have the HEIC originals, converting them to WebP is still worth doing — the damage is done and WebP will not add much more. But if the HEIC files still exist, go direct.

Detour 2: the screenshot

Worth naming because it is so common: photographing something, screenshotting the photo to crop it, then using the screenshot. A screenshot is a fresh lossy capture of an already-lossy image at screen resolution, discarding both the original resolution and any remaining latitude. Crop properly instead — every phone's photo editor does non-destructive crops.

Resize before you compress

A modern phone shoots 12 to 48 megapixels. A web page displays perhaps 1600 pixels on the long edge. Serving the full capture is roughly ten times the pixel data anyone sees, and the quality slider cannot fix that.

Downscale to the size the layout actually uses, then encode. Doing it the other way round produces a larger file that looks worse.

Strip the metadata

Phone photos embed GPS coordinates by default. A photo of your home office published to a public website carries the coordinates of your home. It also carries the device serial, which links every photo you have ever published to the same phone.

Strip metadata for anything public. Keep it only when you specifically need capture data — and be aware that most social platforms strip it on upload, but a direct upload to your own site does not.

The short version

HEIC → resize to display size → WebP at quality 82 → strip metadata → serve with a JPG fallback. One conversion, no wasted pixels, no leaked coordinates.