Skip to content

Image Format Converter

Drop an image or click to browse

Runs in your browser — nothing is uploaded.

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

Modern image formats can save 25-50% file size over JPEG / PNG with no visible quality loss — meaningful when you’re shipping pages to mobile users on slow networks, or paying for asset CDN bandwidth. This tool converts between the four mainstream raster formats entirely in your browser.

How conversion works

The browser’s createImageBitmap() decodes any image format it natively supports into a bitmap. The bitmap gets drawn onto a hidden canvas, and canvas.toBlob(mime, quality) re-encodes it in the target format. Conversion is one-shot — no client-server round-trip, no re-uploading the file each time you tweak quality.

For JPEG output, the canvas is filled with white before drawing because JPEG has no alpha channel. PNG, WebP, and AVIF all preserve transparency.

Format characteristics

FormatLossy?Alpha?Browser supportBest for
JPEGYesNoUniversal since 1996Photos, fallback for old browsers
PNGNoYesUniversal since 2003Graphics, screenshots, transparency, lossless needs
WebPBothYesAll modern browsers (2020+)Web default — 25-35% smaller than JPEG
AVIFBothYesChrome/Edge 85+, Safari 16.4+, Firefox 113+ for display (encoding limited)Smallest files at equivalent quality

Example: shrinking JPEGs for the web

A 1.2 MB camera JPEG converted to WebP at 80% quality typically lands around 280 KB — a 4× reduction with no perceptible difference at normal viewing distances. Same image to AVIF at 80% drops to ~190 KB. For a page with 5 hero images, that’s the difference between a 6 MB page and a 1 MB page.

Example: PNG to WebP for screenshots

A 350 KB PNG screenshot of a UI converts to WebP-lossless at ~120 KB (no quality loss, just better compression). To WebP-lossy at 90% it drops to 60 KB with no visible artefacts on UI elements (sharp edges, flat colors compress especially well in WebP). Whether to keep the lossless or lossy path depends on whether you want bit-exact round-trips.

Example: photo to AVIF

A landscape JPEG (2 MB) → AVIF at 70% → ~250 KB. AVIF’s main strength is photos: its block size and prediction modes were designed for the texture-heavy regions where JPEG most aggressively wastes bytes. The encoding is 5-20× slower than JPEG, but that doesn’t matter for a one-shot conversion.

When format conversion is the wrong tool

  • Lossy → lossy round-trips degrade quality. Converting JPEG to JPEG (or WebP to WebP) at any quality setting passes the image through a lossy encoder again. If you just want a smaller file in the same format, use the compressor instead.
  • GIF for animation. This tool handles still images only. Animated GIFs lose animation. Convert to MP4 with a video encoder, or to animated WebP with a dedicated tool.
  • TIFF, RAW, HEIC as inputs aren’t reliable. Browsers vary in what they decode via createImageBitmap. HEIC specifically needs a separate tool (heic2any) — see the HEIC to JPG converter when shipped.

Common mistakes

Picking PNG for a photo. PNG is lossless, so it preserves every pixel — but photographs have so much information that PNG produces files 5-10× larger than JPEG at indistinguishable quality. PNG is for graphics, not photos.

Using JPEG for screenshots with sharp text. JPEG’s compression algorithm trades fidelity for size in 8×8 blocks. Sharp boundaries (text edges, UI lines) get smeared into “ringing” artefacts. PNG or WebP-lossless preserves them.

Cranking quality to 100% on JPEG. Maximum-quality JPEG is still lossy — and still much bigger than the same image at 92%. You almost never benefit from 100%; 90-95% is the sweet spot.

Converting AVIF to JPEG for compatibility. Yes, AVIF has limited support — but if your audience is on a modern browser (Chrome / Safari / Edge in 2024+), AVIF is fine. For a true universal fallback, ship both AVIF and JPEG via <picture> with <source type="image/avif"> and let the browser pick.

Comparing the source/output sizes against your OS file manager. macOS reports decimal MB; Windows reports binary “MB” (really MiB) under the same label. The same file appears ~5% smaller on Windows than on macOS. The data-size unit converter explains the two conventions.

What this tool does not do

It doesn’t batch-convert multiple files. One file at a time — see the image resizer for batch workflows.

It doesn’t resize. Source dimensions are preserved exactly. To shrink dimensions, use the image resizer. For HEIC-specific input (iPhone photos), the HEIC to JPG converter handles the WASM decode first.

It doesn’t strip metadata (EXIF, ICC). Most browsers’ canvas drops metadata by default; some preserve ICC color profiles. If you need guaranteed metadata stripping, use a dedicated stripper.

It doesn’t upload anywhere. Conversion happens in-browser via Canvas API.

Frequently asked questions

Which format should I pick for the web?

AVIF is the best modern choice — smallest files at equivalent quality, but encoding is slow and not every browser supports it (Safari shipped support in 16.4, March 2023). WebP is the safe default — smaller than JPEG by 25-35% on average and supported in every browser since 2020. JPEG is still a good fallback for photographs that need maximum compatibility (legacy email clients, ancient browsers). PNG is for graphics with sharp edges, transparency, or text — it's lossless so converting a photo to PNG produces a much bigger file.

Why does the tool say 'AVIF not supported' in some browsers?

Because the browser's canvas.toBlob('image/avif') call silently falls back to PNG when AVIF encoding isn't supported. The tool probes by encoding a 1×1 test pixel and checking what the browser actually returns. Firefox supports AVIF for *display* (since 113) but not for *encoding* via canvas — so AVIF conversion is disabled there even though .avif files render fine. Chrome / Edge / Safari (16.4+) support both.

Why does converting a JPEG to a JPEG sometimes lose quality?

Because JPEG is a lossy format — every encode pass throws away some image data. Decoding the original JPEG, re-rendering to a canvas, and re-encoding as JPEG passes the data through the lossy compressor again. For lossy → lossy round-trips (JPEG to JPEG, WebP to WebP, AVIF to AVIF), each round adds artefacts. PNG and WebP-lossless modes don't have this issue. The tool warns you when target format matches source format.

What does the quality slider actually control?

It's the second argument to the browser's `canvas.toBlob()` — a number 0..1 that lossy encoders use as a compression-vs-fidelity dial. The exact algorithm is browser-specific (Chromium uses libwebp, libavif, MozJPEG-style for JPEG), but lower values mean more aggressive quantisation: smoother gradients become posterised, fine detail blurs, file size drops. 92% (the default) matches Chromium's own JPEG default. 70-80% is fine for most web display. Below 50% becomes obviously lossy. PNG ignores quality entirely — it's lossless.

Why does my JPEG output look different even though I used 100% quality?

JPEG at 100% is still lossy — it just uses minimal quantisation tables. The data is decoded to RGB, re-quantised, and re-encoded; even at quality=1.0 the result isn't byte-identical to the input. Also: JPEG doesn't support alpha. If your source has transparency (PNG, WebP-with-alpha), JPEG conversion paints the transparent pixels onto a white background. The tool does this explicitly so you don't get garbage in transparent areas.