Shrink a PNG by converting it to JPEG
PNG is lossless, so a photograph stored as one keeps every sensor detail nobody can see and pays full price for it. JPEG discards the high-frequency detail the eye is worst at, which on a photograph typically gives a file five to twenty times smaller at quality 60 with no obvious change. On flat graphics, screenshots and line art the saving is much smaller and can be negative.
Any PNG, including 16-bit, palette and interlaced ones. It is read in this tab and never sent anywhere.
Quality 60 with 4:2:0 subsampling is the usual sweet spot for an attachment: clearly smaller, and the loss shows only when you zoom in.
Screenshots of text compress badly as JPEG and gain visible fringing around letters, so keep those as PNG and crop instead.
Converting a JPEG that came from a JPEG loses a little more each time, so always start from the original PNG rather than a previous export.
How it works
How it is done
- Read the chosen file in this tab and check the eight-byte PNG signature, then walk the chunk chain for IHDR, PLTE, tRNS, IDAT and pHYs.
- Decompress the concatenated IDAT chunks as one zlib stream, using the browser's own DecompressionStream rather than a bundled inflater.
- Undo the per-row filter — None, Sub, Up, Average or Paeth — working down the image, because each row is predicted from the one above it and the pixel to its left.
- Expand the samples to eight-bit RGBA, whatever the file's colour type and bit depth, reassembling the seven passes first if the PNG is interlaced.
- Composite every pixel onto the chosen background colour using its alpha, so a transparent pixel becomes that colour rather than whatever was underneath it.
- Convert to Y, Cb and Cr with the full-range BT.601 coefficients that JFIF specifies, and halve the resolution of the two colour planes with a box filter if 4:2:0 is in use.
- Take the discrete cosine transform of each 8x8 block, divide by the Annex K quantisation table scaled for the chosen quality, and round.
- Huffman-code the coefficients with the Annex K tables, stuffing a zero byte after every literal 0xFF, and write the JFIF marker segments around the result.
What it assumes
- Transparency is flattened onto the chosen colour before anything else happens, and the blend is done in sRGB rather than in linear light. That is not physically correct — a half-transparent pixel comes out a few per cent darker than it should — but it is what a browser canvas and every image editor do, so the JPEG matches the PNG you were looking at.
- Quality is the scale from Annex K of the JPEG specification, not the browser's. The same number gives byte-for-byte the same file here in every browser, but it will not match "quality 82" in Photoshop or GIMP, because each of those starts from different tables.
- Below quality 90 the two colour channels are stored at half resolution in each direction. On a photograph this is invisible; on saturated text or thin coloured lines it shows as fringing, which is why the setting can be forced to 4:4:4.
- A 16-bit PNG is reduced to eight bits by keeping the high byte of each sample. JPEG is an eight-bit format, so the low byte has nowhere to go.
- Colour profiles are not carried across. An iCCP, gAMA or cHRM chunk in the PNG is ignored and the result is written as plain sRGB, so a wide-gamut image will come out looking flatter than the original.
Common questions
What size limit do email providers actually impose?
Gmail and Outlook both cap a message at around 25 MB including encoding overhead, which is roughly 20 MB of actual attachments. Corporate mail servers are often far stricter — 10 MB is common — and typically bounce the message after sending rather than refusing it up front.
Is it better to resize or to compress harder?
Resize first. A 4000-pixel photo viewed on a phone is being scaled down anyway, so those pixels cost bytes and give nothing back. Dropping to 1600 wide at quality 80 usually beats keeping the dimensions and pushing quality down to 40, which produces visible blocking.
Sources
- Portable Network Graphics (PNG) Specification (Third Edition)
- Recommendation T.81: Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines
- Recommendation T.871: Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)
- RFC 1950: ZLIB Compressed Data Format Specification version 3.3
The full method, worked example and every assumption behind this figure are on PNG to JPEG Converter.