JPG to PNG Converter

Read alongside: this page walks through the plan for one pair. The guide The conversion pipeline follows the same stages — decode, draw, encode, verify — across every pair on the site, and the guides index covers detection, flattening, metadata, and the rest.

What the detector sees

Nothing on this page trusts a filename. The filenames below are illustrative and were checked at build time. The first thing the tool does with a dropped file is read its leading bytes and match them against the format signatures listed on the methodology page; a JPEG opens with FF D8 FF. An illustrative header constructed at build time — FF D8 FF E0 followed by a JFIF segment — is detected as JPEG. The three extensions this page's picker lists, .jpg, .jpeg and .jfif, all claim the same format, so none of them triggers a notice: scan.jfif checks as actual JPEG, claimed JPEG, mismatch false. A file with no extension at all — IMG_4821 — claims nothing (null), so there is nothing to disagree with and it converts from its bytes like any other JPEG.

The notice appears when name and content disagree. holiday.png whose bytes are the JPEG header above checks as actual JPEG, claimed PNG, mismatch true: the row says so and the conversion proceeds from the JPEG that the file actually is. The reverse case — banner.jpg whose bytes begin 52 49 46 46 and carry WEBP at byte offset 8 — is detected as WebP (claimed JPEG, mismatch true). That file is not a JPEG, and this page does not pretend it is: the row names the format it found, and the WebP to PNG lane is where its plan lives.

The plan for this pair

Once the source is known, a pure planning function decides everything the canvas step needs: the output MIME type, whether transparency has to be flattened onto a background, whether a quality parameter applies, and whether the "first frame only" caveat is due. The table is the plan the engine returns for a JPEG source and a PNG target, computed when this page was built.

Two of those rows explain the shape of the tool above. There is no background color picker because the flatten flag is false: PNG can hold per-pixel transparency, so there is never anything to composite, and a JPEG source has no transparency to offer in any case. There is no quality slider because PNG has no quality parameter — and the planner enforces that rather than ignoring a stray value. Ask it for a quality on this pair and it returns an error instead of a plan: "This output format is lossless and has no quality setting." For contrast, the reverse direction carries a default quality of 0.92 and a flatten flag that can be true; that plan is described on PNG to JPG, not here.

Decode, draw, encode

Decoding uses the browser's own JPEG codec through createImageBitmap with imageOrientation: 'from-image'. That option applies the EXIF orientation flag during decoding, so a photo stored on its side with a rotation tag arrives as upright pixels. The bitmap is drawn onto a canvas at its own dimensions; because the plan's flatten flag is false, no fill is painted first. The canvas is then encoded by the browser's built-in PNG encoder with the plan's MIME type, image/png, and no quality argument.

Nothing vendored produces this page's output. The site's two self-hosted encoders — MozJPEG on the Compress JPEG lane and libavif + aom for AVIF output — are not involved, and libheif plays no part in producing a PNG here: the client converts JPEG sources only, and a dropped file that turns out to be HEIC is identified and refused, with a pointer to the HEIC to PNG lane, rather than converted. Decoder and encoder for this pair are both the browser's; the site's own code decides the plan, draws the canvas and verifies the result. The methodology page documents those vendored modules and their licenses for the pages that do use them.

"Lossless" from this point on, not before it

PNG stores the canvas pixels exactly. Whatever the decoder produced is what the file holds — no resampling, no second lossy pass, no change of dimensions. That is the whole of what "lossless" means on this page, and it is worth being precise about where it begins. The JPEG you dropped was itself the product of a lossy encode at the time it was saved; the detail that encode discarded is not in the file, so no conversion can put it back. This tool makes no judgment about how much that was, how the original encoder was configured, or what the image looks like. It cannot know. What it can promise is that from decode onward nothing further is lost — which is the reason to park an image in PNG before software that re-saves files on every edit gets hold of it — and it confirms that the output sniffs as PNG and re-decodes at the canvas's own dimensions.

What re-encoding strips

The PNG that comes out is a fresh encode of pixels, not an edit of the JPEG's bytes, so none of the JPEG's embedded metadata travels with it. EXIF — including GPS location, camera model and timestamps — color-profile tags, and text chunks are all gone. The methodology page presents this as both a feature and a caveat, and so does this one: a converted photo cannot leak where it was taken, and equally a photographer loses copyright fields and the embedded profile. Keep the original. One field is handled before it is discarded: orientation is applied during decoding, so the output stays upright even though the orientation tag itself does not survive.

Output filenames

The filename rule is part of the same planning module. It keeps the base name, swaps the extension for the target's canonical one — png here, just as a JPEG target would receive jpg — and only when the result would carry the input's own name does it append -converted, so the download cannot shadow the original. These are the rule's answers for illustrative names, computed at build time:

Three of the rows deserve a note. Only the final extension is swapped, so a dotted name keeps its earlier dots. A name with no extension simply gains one. And the mislabeled holiday.png from the detection section — JPEG bytes under a PNG name — would, after conversion, want to be called holiday.png again; that is the one case where the suffix appears, and the download is holiday-converted.png.

How the output is verified

A download button on this page means the PNG has already been checked twice. First, the produced bytes are sniffed with the same detector that read the input: the encoder is expected to have written the 8-byte PNG signature, 89 50 4E 47 0D 0A 1A 0A, which the build-time example detects as PNG. If a browser were to hand back some other format, that is reported as an error rather than offered as a mislabeled file. Second, the blob is re-decoded and its pixel dimensions are compared with the canvas that produced it; a disagreement is also an error. The size shown on the row is the output blob's true byte count beside the input's, and where a percent change appears it is computed from those two measured numbers for your file and nothing else.

The about page's shorthand for this pair is "PNG grows"; whether and by how much is the row's measured number, not a prediction. This site limits inputs to 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection, and dimensions never change on this page: the PNG has exactly the pixel dimensions the decoded JPEG had.

What the tool cannot know

The detector reads a signature, not a history. It cannot tell whether a JPEG came straight from a camera or has been re-saved many times, cannot measure how much was discarded along the way, and cannot tell whether the image "looks fine" — a judgment this site declines to make for any file. The color-profile tag is among the metadata that does not survive re-encoding; what the browser's decoder does with it beforehand is the browser's business, and this site makes no claim about it. It cannot repair a damaged file: when the signature says JPEG but the browser's decoder refuses the bytes, the row reports that rather than guessing. And it cannot make the output smaller than the pixels require — the PNG encoder has no quality parameter to turn, which is exactly why the planner refuses one.

Common misreadings

• "PNG means better quality." It means no further loss. The pixels are the decoder's output, stored exactly; what the JPEG's own encode removed is not recoverable.
• "The file got bigger, so the conversion failed." The about page's shorthand for this pair is "PNG grows"; whether and by how much is a measured number, not a prediction. The row states the change and, when the output is larger, says so plainly; the download is still verified.
• "Converting to PNG will give me a transparent background." PNG can carry alpha, but a JPEG has none to give. The plan's flatten flag is false because there is nothing to flatten, and the output is fully opaque. Removing a background is an edit, not a conversion.
• "There should be a quality setting." Quality is a lossy encoder's parameter. For this pair the plan carries quality = null, and a requested value is refused with the message quoted above.
• "My .jfif was rejected." .jfif claims JPEG, and the bytes decide anyway. The build-time check of scan.jfif reports mismatch false.
• "The PNG will be rotated like the file on disk." Orientation is applied during decoding, before the canvas is drawn, so the output is upright; only the orientation tag disappears.
• "It renamed my file." Only when the input was already called .png; see the filename table. A normal holiday.jpg downloads as holiday.png.

Related tools and guides

The guide The conversion pipeline follows the stages above — decode, draw, encode, verify — for every pair on the site, with the plans the engine returns for each; all guides are indexed in one place. Going the other way, with a quality parameter and a flatten flag that can be true, is PNG to JPG. iPhone photos headed for the same lossless PNG landing place start at HEIC to PNG, the lane that loads a decoder. JPEGs that need fewer bytes go to the Image Compressor or Compress JPEG; fewer pixels, the Image Resizer; a different lossy container, JPG to WebP or JPG to AVIF.

Frequently asked questions

Local processing: conversion happens in your browser; your photos never leave your device. Verification steps are on the methodology page.