PNG to JPG Explained

When PNG to JPG pays off — and when it is pointless

The conversion's payoff depends entirely on content. A photograph mistakenly stored as PNG — the common case of a camera export or a screenshot of a photo — carries sensor noise losslessly, inflating the file five to ten times. Converting to JPG at quality 80 produces a visually identical image at a fraction of the size; that is the home-run case. Web screenshots, app-captured images, and downloaded photos frequently arrive in this state, and conversion is pure win.

The pointless cases deserve equal recognition. Small graphics — icons, badges, simple logos — may already be compact as PNG; converting saves little and costs crispness around edges. Flat-color illustrations sometimes compress better as PNG than JPG, so a conversion can actually enlarge them. And any PNG with meaningful transparency loses that property irrevocably. The decision rule: photographic content converts with large gains; graphic content should be measured before converting, not assumed.

The transparency problem: what happens to alpha

JPG has no alpha channel. Conversion must therefore decide what fully and partially transparent pixels become — a process called flattening, where the transparent regions receive a solid background color. The standard choices: white, which is correct for documents and most web contexts; black, which appears when a converter defaults badly and produces the famous 'my logo turned into a black box'; and a chosen brand color for contexts with colored backgrounds.

Partial transparency is subtler. Anti-aliased edges — the soft pixels that make curves and text look smooth — blend the foreground with the background color chosen at flattening. Flatten against white and place the result on dark navy, and every edge carries a faint white halo. The fix is deliberate: choose the flattening background to match the destination's actual background, or if the destination varies, accept that JPG is the wrong format and keep the PNG. Halos are not conversion artifacts to clean up afterward — they are decisions made at conversion time.

Quality settings and what to inspect afterward

PNG sources arrive in two conditions: pristine, or already lossy-damaged from an earlier life as JPG. Both convert fine mechanically, but damaged sources reveal their history under re-compression — artifacts multiply with each generation. Quality 80 is the sane default for photographs; drop to 70 for bulk storage where size matters more than perfection, raise to 85 to 90 for images with smooth gradients or text near edges.

The inspection list after conversion is specific. Smooth regions first — skies, backgrounds — for banding. Text edges for ringing halos. High-contrast boundaries for blockiness. And the flattened background regions for unexpected color, which signals the wrong background choice. Always compare at the display size the image will serve: conversion artifacts that vanish at thumbnail size are irrelevant, and pixel-zoom inspection manufactures problems the audience will never see. Verify at the use size, every time.

Logos, text, and the graphics that should not convert

Some PNGs should never become JPGs, and they share a profile: sharp edges, flat colors, transparency, or small text. A logo flattened to JPG loses its alpha and gains edge ringing; a UI screenshot gains blur around every glyph; a chart's thin grid lines waver. These are not fixable by raising quality — lossy encoding is fundamentally mismatched to the content, and the correct format was already holding the image.

The legitimate exceptions are delivery-driven: a form that accepts only JPG, or an email pipeline that mangles PNG. Then convert with eyes open — white background, quality 90 or higher, dimensions preserved exactly — and treat the JPG as a delivery copy while the PNG remains the master. If the same graphic serves your own website, keep serving the PNG, or better, lossless WebP, which typically trims the size without touching a pixel. Format decisions for graphics are destination decisions; quality settings cannot substitute for the right container.

Realistic size expectations

The savings follow predictable patterns. Photographic PNGs — the biggest win — typically convert to 10 to 20 percent of the original size at quality 80 with no visible change; an 8 MB camera photo stored as PNG becomes a 900 KB JPG routinely. Flat-color graphics may convert to similar, larger, or smaller sizes depending on how the image compresses under each scheme; measure rather than assume. Screenshots land in between — photographic regions compress well, UI regions less so.

Two corrections to common expectations. First, the quality setting moves the result within a range, but the content determines the range — no setting makes a photographic PNG conversion lose. Second, dimensions dominate: a PNG that is also four times too large for its display slot saves more from resizing than from any format change. Run both operations deliberately — resize to destination dimensions, then convert with format-appropriate quality — and the total reduction frequently exceeds 90 percent for oversized photographic PNGs.

Batch conversion and keeping masters

Collections accumulate photographic PNGs quietly — export pipelines, screenshot habits, downloads — and bulk conversion is where discipline prevents loss. Outputs go to a separate folder; originals remain untouched until the conversions verify. Quality uniform across the batch for visual consistency, background color decided once per destination context, filenames preserved so the set stays coherent.

Verification samples should include the batch's edge cases: the flattest gradient, the smallest text, any image with transparency — because uniform settings are only as good as the worst case they were chosen for. After verification, the masters question deserves an honest answer: if the PNGs were just bloated photos, delete nothing until the JPGs prove themselves in use, then archive or discard the originals knowingly. If any converted PNG contained transparency you chose to flatten, that original deserves keeping permanently — flattening is the one conversion step with no undo.

Choosing the background for flattened exports

The flattening decision — which color replaces transparency — deserves more attention than it usually receives, because the choice is baked permanently into the output. The instinct is white, and white is correct when the image's destination is a white context: documents, product sheets, most web content areas. But the right answer is whatever color the image will actually sit on. A logo flattened to white that will be displayed on a dark header shows a conspicuous halo — the rectangle of the fill betraying the conversion. Matching the fill to the known destination eliminates the artifact entirely.

When the destination is unknown or multiple, the honest options narrow. White remains the safest default because light contexts dominate and a white rectangle on a dark background is at least predictable. But the better engineering answer is avoiding flattening altogether: keep the alpha-capable format for assets whose backgrounds vary, and flatten only images with a single confirmed destination. Logos and interface elements are precisely the content that travels across backgrounds, which is why converting them to JPEG is usually a category error rather than a settings question.

Edge effects deserve one more look because they survive conversion: semi-transparent pixels along curves and drop shadows blend with the fill color, and a poor fill choice turns subtle anti-aliasing into visible rims. After any flattening, view the result against both light and dark backgrounds before committing — five seconds of checking catches the halo that a white-only preview hides. The discipline summary: fill with the destination's color when known, keep alpha when destinations vary, and verify against contrast. Transparency is information; flattening is spending it, and like all spending it should be deliberate.

Frequently asked questions