Convert an image to JPG at 20 KB: the format changes, the pixels do not

One picture, three formats, one output

The first thing people expect when converting is that starting from a lossless PNG buys them something. It does not. The compressor decodes the file to a bitmap, drops the original bytes, and then searches for the largest canvas that still fits 20,480 bytes at quality 40%. All three exports decode to the same 3,840,000 pixels, so the search starts from the same place and lands on the same canvas.

Read the last column and you have the only real difference: 773 ms, the gap between decoding a 5.7 MB PNG and decoding a 947 KB WebP. Decoding is the expensive half. The encode — the part that decides what your output looks like — is identical in all three rows because it is being handed identical pixels.

Two consequences worth knowing. First, converting a PNG to JPG at 20 KB is not a double compression; the PNG had no JPEG generation to compound. Second, converting a JPG to JPG is a second generation: the tool re-encodes rather than trimming the existing file, so the original's quality setting is not carried forward — only its pixels are, at whatever quality fits 20 KB.

The 20 KB limit is a ceiling, and the tool fills it

This is the counterintuitive part of converting rather than compressing. If your file already fits the limit but is in the wrong format, the tool cannot pass it through — the format has to change — so it re-encodes, and then it does what it always does: finds the highest quality that still fits the budget. At 900 × 600 that turned out to be 98%.

So: if a form demands JPG and your file is already 3 KB, converting it will hand you a 20 KB file. That is usually fine — forms say "under 20 KB" — but it is not what most people expect, and it is worth knowing before you assume the conversion shrank anything. If you would rather stay small, set a smaller target; the tool will fill whatever ceiling you give it. And if nothing requires JPG, a flat graphic is one of the cases where PNG is the cheaper container at the same budget, which is measured across five kinds of image on the PNG page.

Renaming a .png to .jpg does not convert it

This is the most expensive mistake in the whole conversion workflow, and it is measurable in two rows. Two files, byte-for-byte identical, 2,746 bytes each. Only the extension differs. Both were given the same 20 KB target and the same JPG output format.

The second row was never converted. It was passed straight through — the tool returns a file untouched when it is already under the limit and already reports the output type. Renaming the file is what flipped that second condition, so the file skipped the encoder entirely. The report said image/jpeg, the download was named rename-copy-20kb.jpg, and the bytes were still PNG. Every layer of naming agreed with itself and none of it was true.

This matters because upload checks are not all name-based. Plenty of portals read the first bytes and reject a file whose content does not match its extension; some print an error as unhelpful as "invalid image". If you have ever renamed a file to get past a form and had it rejected anyway, this is why.

The fix is to convert the content, not the name. Rename the file back to .png and run it through the tool with JPG as the output format — that is exactly the first row above, and it produces a genuine JPG.

What a 20 KB JPG does to a transparent PNG

JPEG has no alpha channel, so transparency has to go somewhere. This tool paints the canvas white before drawing the image onto it, then encodes. The result is visible in the corner pixels of the output — and the price of keeping the alpha channel instead is steep.

Bytes per pixel here, both taken as output bytes ÷ output pixels — one sampling point, so the columns compare like with like: 0.01038 for the JPG and 0.07339 for the PNG. That 7× is the alpha channel being paid for in full, in pixels.

The practical rule: decide the background before you convert, not after. If the cutout is going onto a white page, converting is fine and the white fill is invisible. If it needs to sit on a coloured or dark background, composite it onto that colour first in an editor — a JPG cannot carry transparency, and the white pixels are baked in the moment the encoder runs.

Rotation survives the conversion; EXIF does not

Phone photos store their orientation as a tag rather than rotating the pixels. That is the one piece of metadata a conversion cannot lose, because it is applied at decode: the bitmap arrives already upright, and the encoder writes upright pixels.

Measured on a 1200 × 800 photo carrying an EXIF Orientation value of 6 — the tag that means "rotate 90° clockwise to display". The 20 KB output came back at 441 × 661: taller than it is wide. Since 800 × 0.55 = 440 and 1200 × 0.55 = 660, that is the rotated 800 × 1200 view at the 55% scale the tool reported. The rotation is in the pixels now, which is why the output will not display sideways in any viewer.

Everything else in the EXIF block is gone. I read the output file back and searched it: it contains a JFIF header and an ICC_PROFILE block — the browser writes an sRGB profile — and no Exif marker at all. Camera model, capture date, GPS coordinates, the lot. If anything downstream reads those fields, it will find nothing. That is usually a feature for a file headed for a web form, and occasionally not.

Where the file goes while it converts

The conversion runs in the tab. The path is: your file → the browser's own decoder → createImageBitmap → a canvas → canvas.toBlob() → a local object URL you download. There is no upload step in that chain to skip.

Two measurements, because "it stays on your machine" is the kind of claim that deserves evidence rather than a badge. First: with the browser's network log recording every request, a PNG → JPG run at 20 KB issued zero requests between pressing Run and the result panel appearing. Second: with the browser set to offline, the same JPG → JPG run returned 20,234 bytes in 415 ms — byte-identical to the online run of the same file. Nothing was fetched, so nothing was missed.

The honest scope of that claim: it is measured on this site, in this browser, on 22 October 2026. The page does load an analytics tag, which fires on page load and carries no image data. And the decoding and encoding are done by your browser's codecs, so the work happens in software you already have installed. What is not happening is your file travelling to a server and back.

Doing it, in six steps

1. Open the tool. 2. Choose JPG as the output format — this is the conversion, and it is a separate decision from the size target. 3. Set the target to 20 KB. In this tool a KB is 1,024 bytes, so 20 KB is 20,480 bytes; if your form means 20,000, use 19 KB. 4. Drop the file in. 5. Press Compress and read the verdict line: it states the output dimensions and the quality it settled on, which is the fastest way to notice that a picture was cut down harder than you expected. 6. Download and confirm the name ends in .jpg and the file opens — and if the destination is strict, confirm it is really a JPG the way the callout above describes.

If the output looks worse than you can accept, the lever is the target, not the format. At 20 KB a detailed 2400 × 1600 photograph lands at 525 × 350, which is a thumbnail — that is what 20 KB buys for that much detail, and no converter will do better. Raising the target to 50 KB is measured on its own page, and if the limit is coming from a form rather than from you, the portal page checks what three official specs actually ask for.

Questions

Does converting a PNG to JPG at 20 KB lose quality compared with converting a JPG?

Not in the output. All three source formats produced the same 525 × 350 canvas within 9 bytes, because the container is discarded at decode and the encoder only ever sees pixels. The difference is time: 1,195 ms from the PNG, 422 ms from the WebP.

Why did my converted JPG come out bigger than the file I put in?

Because the target is a ceiling the tool fills. A 2,746-byte PNG converted to JPG at 20 KB came back at 20,242 bytes at 98% quality — 7.4 times the input. A format change forces a re-encode, and the encoder then uses the budget it was given.

Does renaming a .png to .jpg convert it?

No. It changes what the file claims to be, which changed the tool's behaviour without changing the bytes: the renamed copy was passed through at 2,746 bytes and stayed PNG while being reported as image/jpeg. Convert the content by running it through with JPG as the output format.

Can I keep the transparent background?

Not in a JPG. This tool fills white before encoding, and the corner pixels of the output read RGB 254, 254, 254. Keeping transparency at the same 20 KB instead gave 527 × 527 rather than 1402 × 1402 — 7.1 times fewer pixels. Composite onto the background colour you want before converting.

Does the conversion strip the metadata?

The EXIF block, yes; the rotation, no. The output carried a JFIF header and an sRGB ICC profile and no Exif marker, while a photo tagged Orientation 6 came back 441 × 661 — upright, because the rotation was applied to the pixels.

Is 20 KB 20,000 or 20,480 bytes?

20,480 in this tool. Every output measured here landed between 20,234 and 20,443 bytes — under 20,480, over 20,000. If the form means 20,000, aim at 19 KB; the cost of doing so is measured on the folder run page, where the same files were re-run at 19 KB.

All figures measured on 22 October 2026 with Chrome 155.0.8059.85 on Windows 11, driving a local copy of this site's compressor, one file per page load, output format set before the target. The test set is eight files built for this page: one 2400 × 1600 picture exported as lossless PNG, JPG at quality 95 with no chroma subsampling, and WebP at quality 90; a 3600 × 3600 transparent cutout; two byte-identical 900 × 600 flat graphics with different extensions; a 1200 × 800 photo with EXIF Orientation 6; and the JPG export again for the offline run. Byte counts, dimensions and quality are the tool's own report; the first bytes and metadata markers of each output were read back out of the produced file rather than inferred. One photograph and one cutout, so these are sample points and not a distribution — a portrait on a plain background compresses to fewer bytes at the same quality, which would move the pixel counts up, not down. Times vary between runs on the same machine; the byte counts did not, which is why they are the numbers quoted. HEIC was not tested here. If you want the pixel budget for each kind of picture rather than the mechanics of converting, that is the 20 KB content-type table; if a single large photo is failing outright, the troubleshooting ladder walks one file down ten targets.