Convert between the formats a browser can really write, then open the output and name the format its first bytes say it is. AVIF, BMP and GIF are disabled because a canvas returns a PNG for all three.
Initializing in your browser…
Render SVG to PNG, JPG or WebP at a chosen size, with the size worked out from the file by the rules that define it and checked against the browser's own rendering.
Turn an image into a data URL whose payload is decoded again and compared byte for byte with the file, with the media type taken from the file's own signature rather than its extension and the size cost of embedding stated in full.
Process many images at once with one operation, with every output decoded again and checked against what was asked for, and the whole batch downloaded as one ZIP.
A 1.43 MB PNG photograph, and the question of which format to ship it in.
Input
comp-photo.png 1.43 MB · compare every writable format at quality 80
Output
PNG 1417.7 KB 97% SSIM 1.0000 worst channel 0 JPEG 291.1 KB 20% SSIM 0.9236 worst channel 129 WebP 283.7 KB 19% SSIM 0.9782 worst channel 108 AVIF, BMP and GIF: this browser cannot write them, so they are disabled
Each row is a real encode, decoded again and compared with the input, so the sizes are file lengths and the SSIM figures are measurements. WebP wins here on both counts at once: smaller than JPEG and much closer to the original. The three formats that are missing were probed on a one-pixel canvas and came back as PNG, which is what canvas.toBlob does for a format it cannot encode, so offering them would mean handing over a PNG under an .avif or .bmp name.
A conversion makes exactly one claim: that the file you download is the format you asked for. This page checks it. Every conversion is encoded, then read back, and the first bytes of the output are printed on the page beside the verdict: a PNG starts 89 50 4E 47, a JPEG starts FF D8 FF, a WebP starts RIFF with WEBP at offset 8. If the signature does not match what was requested, the page says so in red rather than handing the file over. That check is not theoretical. A browser canvas can be ASKED for any format, and for one it cannot encode it returns a PNG with no error at all: the blob comes back typed image/png and carrying the PNG signature. Measured in Chromium on 2026-09-04, PNG, JPEG and WebP encode, and AVIF, BMP, GIF and TIFF all fall back that way. So this tool probes a one-pixel canvas for each format on load, shows the result, and disables everything the browser cannot write. An AVIF button that produces a PNG named .avif is worse than no AVIF button.
Convert to a format older software reads, and confirm from the signature that it really is that format.
See the size and the SSIM before committing, and pick what the transparency becomes instead of finding out afterwards.
Compare every writable format on the actual picture rather than on a rule of thumb; the winner differs between a photograph and a screenshot.
Queue the files, convert once, and take the whole set as a ZIP with each member verified and named correctly.
Three formats can be written here and three cannot, and the page states which is which rather than assuming. JPEG and WebP read the quality argument; PNG does not, so its slider is disabled instead of being left in place to look useful. Whatever the format, the size shown is the length of the blob that will be downloaded, produced by encoding it, not a figure worked out from the pixel count. The output is then decoded a second time and compared with the input pixel by pixel, which is where the SSIM, PSNR, worst-channel and pixels-changed figures come from: a PNG conversion reports a worst channel of exactly 0, and a JPEG at quality 40 does not.
Alpha handling is where conversions usually go wrong. A canvas stores premultiplied alpha and hands a fully transparent pixel back as BLACK, so a cut-out saved as a JPEG lands on a black ground unless something is painted underneath first. When the target has no alpha channel the page counts the fully transparent pixels, says how many there are, and lets you choose the colour they are composited onto, with white as the default rather than as a silent decision.
Metadata cannot survive a conversion, because the picture goes through a canvas and comes back as bare pixels. The page reads the source container first and lists the EXIF, XMP, IPTC, ICC and comment blocks it is about to drop, with the size of each. The colour profile is the one worth thinking about: the browser converts the pixels into sRGB as it draws them, so a wide-gamut source keeps its appearance (measured at an RMSE of 2.05 on a Display P3 photograph against the sRGB original it was built from) while losing the gamut, and anything outside sRGB is clipped and cannot be recovered from the output.
The Compare tab encodes the same picture in every writable format at the chosen quality and puts the sizes and the costs side by side, which is the question a format converter actually answers: which format is smallest for THIS picture, and what does each one cost. Batch mode converts a queue, names each output for the format its bytes say it is, and hands the whole set over as a single ZIP rather than as one download per file.
Because no browser canvas writes AVIF. Asked for image/avif, canvas.toBlob returns a PNG and raises nothing: the blob type is image/png and the first four bytes are 89 50 4E 47. Measured in Chromium on 2026-09-04, the same is true of BMP, GIF and TIFF. Offering the button would mean handing over a PNG under an .avif name, so the tool probes what this browser can really write and disables the rest.
The page reads the output back after encoding and prints its first bytes. A PNG starts 89 50 4E 47, a JPEG FF D8 FF, a WebP RIFF then WEBP at offset 8. If the signature does not match the request, the verdict panel turns red and says which format the file actually is.
No. A lossless format preserves what is there and cannot recover detail the JPEG encoder already discarded. It also normally makes the file several times larger, because PNG has to store the compression artefacts too.
JPEG has no alpha channel, so transparent pixels are composited onto a solid colour. The page counts them, says how many there are, and lets you pick the colour. This matters: a canvas returns a fully transparent pixel as black, so without a deliberate background a cut-out would come out on a black ground.
They are gone. Converting draws the picture on a canvas and encodes it again, and a canvas carries no metadata. The page lists what it is about to drop before you download. The pixels of a wide-gamut source are converted into sRGB as the browser draws them, so the picture still looks right, but the gamut is lost.
No. Every decode and encode happens in the page using canvas APIs, and no file leaves the device.
Images are decoded, edited, and exported entirely inside this browser tab. No originals, exports, or metadata are uploaded.