# PNG to JPG > Flatten a transparent PNG onto a background color you choose, then encode JPG locally. Measured: 1,689,485 bytes down to 351,967, EXIF and depth gone. - URL: https://bytescope.dev/en/image-convert/png-to-jpg/ - Locale: en · Also: [ja](https://bytescope.dev/ja/image-convert/png-to-jpg.md) · [zh-Hant](https://bytescope.dev/zh-Hant/image-convert/png-to-jpg.md) - Runs: Your files never leave your browser — all processing is local. - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does ### What a PNG loses on the way to JPG Transparency is the first and least reversible loss. JPG has no alpha channel at all, so every transparent or semi-transparent pixel is composited onto the background color chosen in the settings above — white unless you change it — and the converter raises a warning as soon as it finds alpha in the source. A logo exported on a transparent background becomes a logo on a rectangle. Nothing in the output records where the transparency used to be, so an editor cannot tell the flattened pixels apart from pixels that were always that color. The second loss is specific to what these files usually contain. The measured encode uses 4:2:0 chroma subsampling, which keeps full luminance detail but stores color at half resolution in both directions. Photographs tolerate that; the screenshots, diagrams, charts and UI exports that live in PNG files do not. Red text on a dark panel, thin colored rules and one-pixel borders pick up a visible fringe that no quality setting removes, because the color information is thrown away before the quality slider's quantization step even runs. The rest is the usual re-encode toll. A 16-bit source is reduced to the 8-bit canvas before encoding, an embedded ICC profile and any EXIF block are not copied into the output, and an animated PNG contributes only its first frame — the converter closes the decoder and warns you rather than writing something the target format cannot represent. Finally, quality 85 is lossy: even for a photograph that started life losslessly, fine texture and edges are approximated once and stay approximated. ### How the file size changed in a measured run The 2026-09-12 run measured a 1280 × 854 PNG of 1,689,485 bytes, written with "optimize (oxipng)" on — this tool leaves that option off by default. Encoding it as a 4:2:0 JPG at quality 85 produced 351,967 bytes — roughly 79% smaller for this photographic sample. That measurement was made with sharp, because the script runs in Node; your browser encodes through canvas, which picks its own quantization tables, so expect a few percent either way rather than the exact number. The direction is reliable for photographs. For a flat screenshot the saving is far smaller, and a simple diagram can even come out larger, because JPG has no cheap way to store large areas of one exact color. ### When you should not convert PNG to JPG Do not convert anything that needs its transparency: a logo, an icon, a sticker, or any image meant to sit on an unknown background. Do not convert screenshots of text or UI, where chroma subsampling and ringing around sharp edges are exactly the artifacts people notice. Do not convert a working master you will edit again, because every re-save is another generation of loss. If the goal is a smaller file for the web, WebP and AVIF both hold alpha and beat this target at the same visual quality, and both are offered here. JPG earns its place when the file has to be opened by something old, printed by a lab, or accepted by a form that lists only two extensions. Conversion happens entirely in your browser — no upload, no queue, no watermark. Drop in as many files as you like and download them individually or as a zip. ## Limits Transparency is the first and least reversible loss. JPG has no alpha channel at all, so every transparent or semi-transparent pixel is composited onto the background color chosen in the settings above — white unless you change it — and the converter raises a warning as soon as it finds alpha in the source. A logo exported on a transparent background becomes a logo on a rectangle. Nothing in the output records where the transparency used to be, so an editor cannot tell the flattened pixels apart from pixels that were always that color. The second loss is specific to what these files usually contain. The measured encode uses 4:2:0 chroma subsampling, which keeps full luminance detail but stores color at half resolution in both directions. Photographs tolerate that; the screenshots, diagrams, charts and UI exports that live in PNG files do not. Red text on a dark panel, thin colored rules and one-pixel borders pick up a visible fringe that no quality setting removes, because the color information is thrown away before the quality slider's quantization step even runs. The rest is the usual re-encode toll. A 16-bit source is reduced to the 8-bit canvas before encoding, an embedded ICC profile and any EXIF block are not copied into the output, and an animated PNG contributes only its first frame — the converter closes the decoder and warns you rather than writing something the target format cannot represent. Finally, quality 85 is lossy: even for a photograph that started life losslessly, fine texture and edges are approximated once and stay approximated. ## FAQ ### What happens to a transparent PNG when JPG has no alpha? Every transparent pixel is blended onto the background color shown in the settings, white by default, and a warning tells you it happened. Pick the color that matches where the image will sit — a logo flattened onto white looks wrong the moment you drop it on a dark page. ### Why does text in a screenshot look fringed after PNG to JPG? The encoder stores color at half resolution in each direction, so a one-pixel colored edge is reconstructed from neighbouring blocks. Raising quality reduces the ringing but not the fringe, because the chroma was discarded first. Screenshots belong in PNG, WebP or AVIF. ### Can I recover the transparency from the JPG later? No. The alpha channel is not stored in a reduced form; it is gone, and the flattened pixels are ordinary opaque pixels. Recreating the cut-out means selecting and erasing the background by hand, which is why the original PNG is worth keeping alongside the JPG. ### Are my images uploaded anywhere? No. Conversion happens inside your browser using the canvas API and a Web Worker — files never leave your device. There is no upload step, no queue and no file size limit beyond your machine's memory. ### Is EXIF metadata kept in the converted image? No — and that's a feature. Re-encoding through the canvas strips all metadata: GPS location, camera model, timestamps and color profiles. The output contains pixels only, which is usually what you want before sharing an image publicly. ### Can I convert many images at once? Yes. Drop or paste any number of files; each is converted in the background with its own progress and download button, and you can grab everything at once as a .zip archive. ### Will converting lower my image quality? It depends on the target. The converter always decodes to raw pixels and re-encodes, whichever formats are involved, which is also how metadata gets stripped. For lossless targets (PNG, and GIF within its 256-color limit) the pixels stay identical to what was decoded; for JPEG, WebP and AVIF the quality slider controls the trade-off, and converting a file that is already lossy adds one more generation of loss.