WebP, PNG or JPG?

Choose in this order: destination, transparency, detail, bytes

First check which formats the receiving application accepts. Then decide whether the image needs transparent pixels. After that, judge how much visible compression change the content can tolerate. Only compare file sizes among candidates that meet those requirements. The smallest unusable file does not help the workflow.

A product cutout can need alpha; a screenshot can need crisp text; an opaque photo can prioritize a compact delivery. Those are different decisions even when all three images share the same width and height. Keep the source and make purpose-specific exports rather than declaring one format best for every image.

1. Destination accepts the format → the file can enter the workflow.
2. Alpha is required → keep a format and export path that retain transparency.
3. Fine detail matters → compare actual outputs at the intended size.
4. Byte cap is strict → verify the saved file, not a predicted percentage.

Transparency: what the checkerboard really means

Transparency is information attached to pixels, not a white background that the converter can recognize and erase. A transparent logo can sit over a presentation, a colored product card or a dark website without bringing a rectangular backdrop with it. An opaque white pixel stays white after conversion.

The preview uses a checkerboard to make empty and partially transparent areas visible. The pattern belongs to the interface and is not added to the downloaded image. After downloading, place the result on both a light and a dark background. This reveals pale fringes, baked-in backgrounds and edges that a white preview can hide.

Alpha channel → controls pixel opacity → allows the background underneath to show through.

Reference: W3C: PNG specification

How to compare formats without mixing up the variables

Use the same source and the same visible dimensions for each candidate. A 600 px thumbnail and a 2400 px image are not a useful format-only comparison. Note the encoder and quality setting, then compare appearance as well as bytes. The same quality number across two encoders does not establish equal visual quality.

Include demanding content: small text for a diagram, gradients for an illustration, and hair or fine texture for a photograph. If transparency matters, use the same background when viewing the candidates. Record which sample meets your requirements rather than turning a result from one easy image into a universal size-reduction claim.

Reference: MDN: Canvas toBlob()

Keep a master; create a delivery copy

A master is the source you keep for later editing and exports. A delivery copy is tailored to one destination. A PNG master can generate a WebP for a compatible website and an opaque JPG for a form. Saving both deliveries does not require replacing the source. Organize them by purpose so a later edit starts from the strongest available image.

Avoid a chain such as JPG → WebP → JPG for repeated revisions when the original is available. Both delivery steps can be lossy. A final PNG can stop further lossy encoding of the working pixels, but it cannot reverse earlier damage. If precise color profiles or archival metadata matter, a browser canvas conversion is not a replacement for your specialist master workflow.

Dimensions, orientation and the size of the preview

Changing the format does not resize or crop the image. A 2400 × 1600 landscape stays at that pixel size. An orientation tag can require a rotation or a reflection; when a portrait is rotated into its visible orientation, width and height may exchange places. That is an orientation correction, not a reduction in resolution.

The preview is fitted to the available space and can use a smaller display copy. Judge output dimensions from the downloaded file, not from how large it appears on your screen. For print work, also check the required physical size and resolution in your design application; a format conversion does not prepare a complete print specification.

EXIF, GPS, color profiles and what is not preserved

The output is a newly encoded image. Original EXIF, GPS and XMP records are not copied; an encoder may add its own technical fields. Orientation is applied to the image rather than relying on the original orientation tag in the download. Keep the original if you need camera settings, capture dates or an archival record.

Working pixels use an sRGB canvas where supported. Exact source ICC profiles, HDR information and 16-bit precision are not retained. A screen that looks similar is not proof of identical color data. For calibrated print, scientific measurement or preservation of high-bit-depth originals, use a workflow designed for those requirements.

A practical check before you use the result

A successful download is the start of the final check. Open the output in the application that will actually use it. A slide editor, upload form and image viewer can handle the same file differently. Checking the intended destination catches problems that the browser preview alone cannot reveal.

1. Confirm the extension and that the destination opens the image without an error.
2. Check width, height and visible orientation; compare them with the original.
3. Inspect fine text, diagonals, hair, shadows and gradients at 100% zoom.
4. Place transparent graphics on both a light and a dark background.
5. Compare the actual byte size with the destination limit before submitting.
6. Keep the source until every downloaded file has been checked.