Convert CR2 to WebP

The reason to pick WebP over JPEG is bytes. For the same visible quality it typically lands a quarter to a third smaller, and on a page with thirty photographs on it that saving compounds into something a visitor can feel. Largest Contentful Paint is usually an image, and on a photography site it is always an image.

The reason it is safe to pick is that the compatibility question closed. WebP is supported in every current browser and standardised as RFC 9649. Serving it no longer requires a fallback chain, a picture element with three sources, or a conversation with a client about old versions of Safari.

Here is the part most pages would leave out. A CR2 is not developed here; the converter locates the finished JPEG that your Canon wrote inside the file at the moment of capture and works from that. Producing a WebP means decoding that JPEG and encoding it again, so the picture passes through two lossy encoders on its way to your website.

At the default quality of 82, and at the pixel dimensions a web page actually displays, the second pass is not something a viewer will spot. It is still worth understanding for one practical reason: always convert from the CR2, not from a WebP or JPG you exported earlier. Each additional round trip costs a little more, and the chain has already used one of its lives.

The embedded preview is the camera’s full-resolution rendering — a 5D Mark IV gives 6,720 pixels across, a 5DS 8,688. A responsive image on a website is served at perhaps 1,600 or 2,400 pixels for a high-density display, and everything beyond that is bytes the browser downloads and throws away.

So set a maximum width. Going from 6,720 to 2,000 pixels removes about nine-tenths of the pixel count, which dwarfs anything the quality slider can do and costs nothing visible. Dropping quality from 82 to 60 on a full-size image is the wrong lever pulled in the wrong order.

The output is the camera’s own rendering, with the picture style you had loaded — Standard, Landscape, Faithful — already applied and unchangeable. If the shoot needs consistent grading before it goes online, that has to happen in a raw developer working from the CR2, and this page is the wrong stage of the pipeline.

The metadata also goes, because a re-encode does not carry EXIF through. For public web images that is a benefit: a property listing photographed with a GPS-tagging body should not publish the coordinates, and a portfolio does not need to broadcast the lens. If you want credit or copyright fields in the file, they have to be written into the WebP afterwards.

This runs in your browser. For a working photographer that is not a detail — an unpublished shoot, a client’s property, a set under embargo — none of it goes anywhere. The conversion is JavaScript and a WebAssembly encoder downloaded to your machine, operating on files that stay on it.

It also means the batch is bounded by your computer rather than by a plan. Drop a folder, get a ZIP, with a 100 MB per-file ceiling on the free tier that no CR2 comes near.

AVIF compresses better than WebP at the same quality, sometimes considerably, and it is also supported broadly now. If page weight is the only consideration it is the stronger choice.

WebP wins on the other axes: it encodes far faster, which is what you notice converting two hundred frames in a browser tab, and every CMS, image plugin and CDN understands it without configuration. For a gallery of Canon photographs the difference in delivered bytes is smaller than the difference in the hour you spend getting there.

The output arrives named after the source, so IMG_4821.CR2 becomes IMG_4821.webp. That is convenient for matching a delivered gallery back to the originals and unhelpful for search, because a camera’s serial filename tells a crawler nothing.

Rename before uploading, and write alt text that describes the photograph rather than repeating the filename. Neither of those is something a converter can do for you, and both matter more to how the gallery performs than the choice between WebP and JPEG does.

WebP cannot store an image longer than 16,383 pixels on either side. Nothing that comes out of a Canon DSLR approaches that, so for a straight CR2 conversion the limit is theoretical.

It becomes real if you stitch first. A panorama assembled from eight or ten CR2 frames can pass 16,383 pixels easily, and at that point WebP is simply not able to hold it — the picture has to go out as JPEG, or be split, or be scaled down. Worth knowing before a stitching session rather than after.

Keep the CR2 files as the masters, on the assumption that they will outlive whatever the site is built in. Extract WebP at the size the site actually serves, and regenerate rather than upscaling if the design later changes.

For the handful of images that carry the page — a hero, a cover, the one everybody looks at — it is worth going back to the CR2 in a raw developer and doing the work properly. For the other ninety per cent, the camera’s own rendering resized to 2,000 pixels is indistinguishable from the careful version and takes seconds instead of minutes.