PNG to JPG Converter

What the detector sees before anything is converted

The first thing this page does with a dropped file is read its leading bytes — not its name — and match them against the format signatures the engine knows. A PNG begins with the 8 bytes 89 50 4E 47 0D 0A 1A 0A; the detector run on exactly those bytes at build time reports PNG. The filename is then compared against that reading; the names that follow are invented, and the bytes are constructed signatures. For screenshot.png whose bytes really are PNG, the check returns actual PNG, claimed PNG, mismatch false — nothing to report. For a file named photo.png whose bytes begin FF D8 FF, the same check returns actual JPEG, claimed PNG, mismatch true: that is the visible notice described on the methodology page, and the engine proceeds from what the file actually is, never from the extension. The reverse case — logo.jpg that is really PNG — reads actual PNG, claimed JPEG, mismatch true, and is treated as the PNG it is.

Detection is a pure function over the bytes: no decoding has happened yet, nothing has been sent anywhere, and the answer does not depend on which browser is running it. The same function runs once more on the finished output, which is how the verification step described below works.

What the plan decides for PNG to JPG

Every conversion on this site is decided before it is performed, by a planning function that takes only the detected source format, the target format, and your two controls. Running it for this page's pair with no options produces the following plan. These values are computed at build time by the same code the tool runs in your tab, so the copy cannot drift from the behavior:

Output type: image/jpeg, saved with the .jpg extension.
Flatten transparency onto a background: true. The JPEG target's capability record says it can carry per-pixel transparency: no. PNG can, so the plan always schedules a composite step for this pair.
Background color: #ffffff unless you change it — the color control above feeds this field directly.
Quality: 0.92 on the engine's 0–1 scale, which the slider shows as 92. The JPEG target is lossy (yes), so a quality parameter exists at all; a PNG target has none.
First frame only: false. PNG is not one of the containers the engine treats as animatable, so the "first frame only" caveat that GIF, WebP, and AVIF sources carry does not appear on this page.

Change the controls and the plan changes with them. Setting the background to an illustrative #1f2937 and the slider to 80 yields a plan with background #1f2937 and quality 0.8; the flatten flag stays true, because it is decided by the formats, not by your choices. The planner refuses rather than guesses when an option is out of bounds: a quality beyond the scale returns the error "Quality must be between 0.05 and 1.", and a background that is not a hex color returns "Enter the background as a hex color like #ffffff." Asking for a quality on a lossless target returns "This output format is lossless and has no quality setting." — which is why the sibling JPG to PNG page has no slider.

Guide: the planner's capability table — which of the 4 output formats keep transparency, what the background prompt does, and the flatten flag demonstrated for every pair — is written up in Transparency and flattening. This page covers only the PNG to JPG case.

Why the background color is asked for first

A PNG may carry an alpha channel; a JPEG cannot. Because the plan is decided from formats rather than from pixels, the engine does not inspect your file to see whether any pixel is actually transparent — the flatten step is scheduled for every PNG converted here. The pixels are drawn to a canvas that has first been filled with the background color, so transparent and semi-transparent areas are merged onto it and fully opaque pixels are drawn over it unchanged. Each converted row confirms when flattening happened and onto which color, so the result is never a silent surprise.

The choice is also permanent: a JPEG holds no alpha, so once the transparency has been composited away, no later conversion can recover it. If your image needs to keep its transparency, this is the wrong page. Of the formats this site can produce, the capability table says transparency is kept by PNG (yes), WebP (yes), and AVIF (yes), and by JPEG: no. PNG to WebP and PNG to AVIF are the 2 lossy destinations that keep alpha. If you are not sure the destination is a flat color, match the color of wherever the image will be placed, or keep the PNG.

The quality number, and which encoder reads it

The quality parameter on this page is passed to the browser's own JPEG encoder — the canvas re-encode the methodology page describes — not to a vendored codec. The site does ship a second JPEG encoder, MozJPEG, but only on the Compress JPEG lane; this page is not that lane, so its quality number goes to the browser's canvas encoder. The engine's default for a JPEG target is 0.92, shown on the slider as 92, and the planner accepts exactly the range its own error message states above.

What the number is not: it is not a percentage of the original's quality, not a percentage of the original's size, and not a recommendation. The site publishes no quality recommendations and no blanket compression percentages, because no setting and no percentage is true for every image. What you get instead is measurement: each row shows the input and the output as true byte counts for your file, so moving the slider and dropping the file again compares real results rather than advertised ones.

What the output is called

The output filename is derived, not typed: the engine keeps the base name up to its last dot and swaps the extension for the JPEG target's canonical one, .jpg. The filenames here are invented; the outputs are the engine's: screenshot.png becomes screenshot.jpg; Screenshot 2026-10-02 at 09.14.PNG becomes Screenshot 2026-10-02 at 09.14.jpg, because only the last dot is treated as the extension; a file with no extension at all, export, becomes export.jpg. One case gets a suffix: when the derived name would equal the input name, compared ignoring case — a logo.jpg whose bytes are really PNG, converted here — the output is logo-converted.jpg, so the download cannot shadow the original.

What re-encoding strips

The output is built from decoded pixels, so nothing stored beside those pixels in the PNG container survives: text chunks, color-profile tags, and any EXIF block — including GPS location, camera model, and timestamps where a PNG carried them — are all absent from the JPG. The methodology page presents this as both a feature and a caveat, and it is both: a converted image cannot leak where it was taken, and equally, copyright fields and profiles are gone, so keep your originals. One thing is applied before it is discarded: orientation. Decoding uses imageOrientation: 'from-image', so an image whose metadata says it is rotated comes out upright even though the tag itself does not survive. The metadata guide covers the full list.

How the output is verified before download

A download button appears only after two checks. First, the produced bytes are sniffed with the same detector that read the input: the engine run on a JPEG's leading bytes FF D8 FF reports JPEG, and a result that does not sniff as JPEG — a browser silently substituting another encoding — is reported as an error rather than offered as a mislabeled file. Second, the blob is decoded again and its pixel dimensions are compared with the plan. The byte counts on the row are the output blob's true size.

Where a row shows a percent change, it is arithmetic on those two measured counts and nothing else. To show the rule rather than make a promise, here is the same function run on invented numbers at build time: 2,400,000 bytes in and 600,000 out reads "75% smaller"; 300,000 in and 318,000 out reads "6% larger — keep your original"; 1,000,000 in and 999,700 out reads "less than 0.1% smaller". These are illustrations of the arithmetic, not predictions for any PNG — the site publishes no blanket compression percentages anywhere. A JPG can come out larger than the PNG it came from, and when it does the row says so in the same breath; the honest move is then to keep the original.

What the tool cannot know

The plan is decided from formats, filenames, and numbers, so there are things it does not and cannot judge. It does not know whether your PNG uses its alpha channel, only that PNG can and JPEG cannot — hence the unconditional flatten. It does not know whether the destination background is the color you picked. It does not know whether a lossy result looks acceptable to you: the JPEG target is lossy by capability (yes), which means the pixels are not reproduced exactly, and the only honest statements the tool can make about the result are its measured size and its verified dimensions. And it does not know whether the size trade was worth making — that is the comparison the row's two byte counts exist to let you make.

Common misreadings

"Choosing white keeps the transparency." No — white is the color the transparency is merged onto. The plan's flatten flag is true for every PNG to JPG conversion, whatever color is chosen.
"The quality number is how much of the original survives." It is the encoder's quality parameter on the engine's scale (0.92 by default), and the only measures of the result are the row's byte counts and verified dimensions.
"It's just a rename." The filename swap is the least of it: the file is decoded to pixels, composited, and re-encoded as image/jpeg. Renaming a .png to .jpg yourself produces exactly the extension mismatch the detector flags.
"The first-frame caveat applies here." It does not: the plan's first-frame flag is false for a PNG source.
"My PNG's text and profile tags come along." They do not survive canvas re-encoding; see above.
"A larger output means the tool failed." The row reports measured bytes; a larger result is reported as larger, and the original is the right file to keep.

The reverse direction is JPG to PNG. iPhone photos that need the same everywhere-compatible JPG treatment start at HEIC to JPG. To hit an exact file-size budget in KB, the Image Compressor binary-searches the quality for you. For dimension changes, use the Image Resizer. The mechanisms behind every page are written up in the guides, starting with Transparency and flattening.

Frequently asked questions

Why does this page ask for a background color before converting?

Because JPEG cannot carry transparency and PNG can. The engine's plan for a PNG source and a JPEG target sets its flatten flag to true for every file, so transparent and semi-transparent pixels are merged onto a color before encoding — #ffffff unless you change it. Asking first makes that a visible choice rather than a silent default, and each converted row records the color that was used.

My PNG has no transparent pixels — does the flatten change anything?

Not visibly: opaque pixels drawn over a background are unchanged. The flag is still set, because the plan is decided from the two formats rather than by inspecting your pixels, and the row still records the color the image was composited onto.

What does the quality number mean?

It is the parameter handed to the browser's JPEG encoder, on the engine's 0–1 scale — the default for a JPEG target is 0.92, which the slider shows as 92. It is not a percentage of the original's quality or size, and this site publishes no recommended setting: the row shows the real output size for your file, so compare settings by measurement rather than by rule of thumb.

Will the JPG keep every pixel exactly as the PNG had it?

No. The JPEG target is lossy by capability, so the pixels are re-encoded approximately; only a lossless target reproduces them exactly, which is why asking the planner for a quality on a PNG target returns "This output format is lossless and has no quality setting." If exactness matters, keep the PNG.

What will the output file be called?

The base name with the extension swapped for .jpg — on invented names, screenshot.png becomes screenshot.jpg, and only the last dot counts, so Screenshot 2026-10-02 at 09.14.PNG becomes Screenshot 2026-10-02 at 09.14.jpg. If the derived name would equal the input's — a .jpg that was really PNG — the output gets a suffix, as in logo-converted.jpg, so the download cannot shadow the original.

Is metadata removed?

Yes — canvas re-encoding strips embedded metadata: text chunks, color-profile tags, and EXIF including GPS location, camera model, and timestamps. That protects privacy but also removes copyright fields, so keep your originals if those matter. Orientation is applied during decoding, before the tag is discarded, so the image stays upright.

Do my PNGs get uploaded for conversion?

No. The conversion is JavaScript in your own tab. The site ships a security policy that blocks talking to any other server, and the methodology page walks you through confirming zero uploads in DevTools.

Why might the JPG come out larger than the PNG?

Because size depends on the image, and the tool measures rather than predicts. The row's percent is arithmetic on the two true byte counts — on invented figures, 300,000 bytes in and 318,000 out reads "6% larger — keep your original". When that happens the honest move is to keep the original; the site publishes no blanket compression percentages, because none is true for every image.

Local processing: nothing you drop here is transmitted anywhere — the conversion is your browser's own JavaScript, and the methodology page shows how to verify it.

Convert PNG files to JPG