Converting an image between JPEG, WebP and PNG sounds like a format setting. It is really three different decisions, and getting them confused is why converted images sometimes come back with a grey box, a wrong size, or visibly worse quality than the file you started with.
Here is what each format actually stores, and what changes when you convert.
What each format holds
JPEG stores a lossy DCT-compressed image, 8 bits per channel, no alpha. Its strengths are photographic data and small files; its weaknesses are sharp edges, text, and anything that will be edited again.
PNG stores lossless pixels with a full alpha channel. Great for screenshots, UI, logos and anything with transparency or hard edges; large for photographs.
WebP does both: lossy and lossless modes, plus alpha in either. It is typically 25-35% smaller than JPEG at comparable perceived quality, and it supports transparency that JPEG cannot.
So the first decision is not "which is better" but "does this image have transparency or hard edges, and will it be re-edited".
Decision 1: alpha
If the image has transparent pixels, JPEG is out — full stop. Converting RGBA to JPEG has to flatten the alpha channel onto something, and what it flattens onto depends on the encoder:
- Some flatten onto white.
- Some flatten onto black (visibly catastrophic on dark logos).
- Some flatten onto the background colour stored in the file, which may itself be undefined.
This is the source of the classic "my PNG became a black box" bug. If you must have JPEG, flatten deliberately onto a colour you chose, and check the result rather than assuming.
Decision 2: repeated lossy conversion
Every JPEG save is a new lossy generation. Decode → re-encode at quality 85 → decode again is not the same image; each pass loses a little high-frequency detail and adds a little ringing, concentrated around edges.
The visible symptom after 3-4 generations is "mushy text and haloed edges", which people usually blame on the source. If a workflow requires multiple edits, keep a lossless master (PNG, or a full-quality JPEG at q95+) and export derivatives from it, rather than editing the last export.
WebP has the same property in lossy mode. Being newer does not make it immune.
Decision 3: the colour profile
Here is the one that quietly ruins conversions: an image tagged with a wide-gamut profile (Display P3) converted by a tool that ignores the profile will display with shifted, oversaturated colours. A tool that honours the profile but then strips it from the output produces a file that looks right on your machine and wrong on someone else's.
For web delivery the safe pattern is:
- Convert to sRGB if the image is not already.
- Keep the sRGB profile embedded (or at minimum, do not leave an image tagged P3 but containing sRGB data).
- Verify by opening the output in a different tool than the one that produced it.
Most "the colours changed after upload" reports are this, not compression.
Decision 4: resampling, which is separate from format
Changing pixel dimensions is a different operation from changing format, and both are often presented in the same dialog.
- Downscaling is safe if you use a decent filter (Lanczos or a two-pass box filter). Done naively — nearest neighbour — it aliases, and thin lines become dotted.
- Upscaling cannot add information. Bicubic interpolation produces a soft, slightly blurry result; model-based upscalers produce plausible invented detail. Neither restores what was never captured.
- DPI is metadata, not pixels. Changing 300 DPI to 72 DPI without changing pixel dimensions does not change the image at all; it changes the number a printer reads. A 3000×2000 image at 72 DPI is the same data as at 300 DPI. People routinely "resize for print" by only changing DPI and get a file no sharper than before.
A checklist that catches all four
Before publishing a converted image:
- Does the output have the alpha you expect? (Open it somewhere that shows a checkerboard.)
- Are the pixel dimensions what you intended — not just the DPI field?
- Did you edit the master, or a derivative of a derivative?
- Do the colours match when opened in a second application?
- At 100% zoom, is the text still crisp? (The most sensitive test for lossy damage.)
Five checks, thirty seconds, and they catch the entire class of conversion accidents.
I build aiphotoeditor.best, where format conversion and compression run in the browser as ordinary pixel operations — JPEG, PNG and WebP in and out, with the pixel dimensions shown before you download. That layer is free and unlimited because it costs nothing to run; the AI features (enhance, restore, cutout, headshots) are a separate, explicitly counted path with three free runs a day.
Honest limits: the converter does not invent detail when upscaling, and it does not run colour-profile conversion for you — if your source is Display P3, convert to sRGB in a tool that manages profiles before the file reaches the web. That is a real gap, not a hidden feature.
Top comments (0)