Utilify

JPG to PNG Converter

Convert JPG images to PNG in your browser. Pixel-exact output, transparency-ready, and the size increase is shown before you download.

Built and maintained by Jay SooUpdated September 8, 2026

How to use JPG → PNG

  1. 1
    Drop a JPG

    Select or drag in a JPG file.

  2. 2
    Convert

    PNG output is generated instantly using Canvas, with the output dimensions and how many times larger the PNG is than the JPG shown underneath.

  3. 3
    Download

    Save the new PNG, or convert another file.

About JPG → PNG

Converting JPG (lossy) to PNG (lossless) is usually done for one of three reasons: you need transparency, which JPG does not support; you want to keep editing without compounding compression artifacts on every save; or a workflow simply demands PNG — most design software, print pipelines, and app icon specs do.

Expect a considerably bigger file. Running the same four 900×600 test images through this converter in Chrome 153, with the sources encoded at JPEG quality 0.8, the PNG came out 3.6× to 9.6× the size of the JPG: a grainy photo went from 57.1 KB to 549 KB, a UI screenshot from 61.8 KB to 224 KB. PNG stores every pixel exactly, and the pixels it stores are the ones the JPEG left behind — nothing the original encode discarded comes back. The converter prints that multiple underneath the output so the file size is not a surprise after you download it.

Just how faithful the conversion is turns out to be the whole point. Decoding our own PNG output and comparing it pixel by pixel against the decoded JPEG gives a maximum per-channel difference of 0 — an exact copy — for all four test images in Chrome 153, Firefox 155, and WebKit 26.6. Meanwhile that JPEG sat 2.94 mean absolute error away from the untouched original photo, with individual pixels on a red-on-white edge off by 112 out of 255. The conversion preserves all of it perfectly, which is exactly why it cannot repair anything. What you gain is a format that will not degrade on the next save, and that is what makes PNG the right base for an editing pipeline even though the starting quality is unchanged.

Transparency is the other main reason to convert, with a nuance worth stating plainly. A JPG has no alpha channel, so the PNG you get starts fully opaque; the conversion makes the file capable of holding transparency but does not create any. Getting a transparent background still means erasing or masking it in an editor — PNG is the prerequisite, not the eraser.

For the common case of needing a PNG because a tool, store, or print service demands one, this is the quick and private answer: conversion runs entirely in your browser through the Canvas API, so the image never leaves your device. Drop the JPG, download the PNG, and move on — with the realistic expectation of a larger file that looks the same, which for format-compatibility purposes is precisely what you want.

How much the file grows, measured on four kinds of image

Four 900×600 sources — a grainy photograph, a UI screenshot full of small text and hairlines, a flat logo-style graphic, and saturated red text on white — each saved as a lossless PNG for reference, then encoded to JPEG at quality 0.8 and run back through this converter. Byte counts are from Chrome 153.

Source imageJPEG (quality 0.8)PNG from that JPEG× the JPEGPNG of the untouched original× that PNG
Photograph, fine grain57.1 KB549 KB9.6×866 KB0.63×
UI screenshot, small text61.8 KB224 KB3.6×90.5 KB2.5×
Flat graphic, few colours9.6 KB53.3 KB5.6×17.2 KB3.1×
Red text on white68.3 KB259 KB3.8×58.8 KB4.4×

The last column is the counterintuitive one. For anything with hard edges, the PNG you get out of a JPEG is several times larger than the PNG you would have had by saving the original losslessly in the first place — JPEG ringing turns flat colour into low-amplitude noise, and noise is what PNG compresses worst. The grainy photograph goes the other way (0.63×) because the JPEG smoothed its grain away before PNG ever saw it. Absolute bytes vary by browser, since each engine ships its own JPEG and PNG encoders, but the pattern held in all three we measured: edge-heavy sources landed at 2.5× to 4.6× the pristine PNG in Chrome 153, Firefox 155, and WebKit 26.6, and photographs stayed below 1× in every engine.

When to use JPG → PNG

  • Editing pipeline

    Convert a JPG to PNG before further edits to prevent additional JPEG re-compression artifacts.

  • Software requirements

    Some design tools, app stores, and print services only accept PNG — convert when needed.

  • Adding transparency

    After conversion you can edit the image to add an alpha channel (e.g., removing a background).

What we measured going wrong in a JPG → PNG conversion

  • Converting to PNG to clean up a bad JPEG

    The conversion is bit-perfect, and that is precisely the problem. Decoding this tool's own PNG output and diffing it against the decoded JPEG gives a maximum per-channel difference of 0 — an exact copy — on all four test images in Chrome 153, Firefox 155, and WebKit 26.6. Whatever the JPEG encoder did survives the trip intact: the test photograph sat 2.94 mean absolute error from the original, and a pixel on a saturated red edge was off by 112 out of 255. If the artifacts bother you, the fix is re-exporting from the original source, not changing format.

  • Assuming a small JPEG produces a small PNG

    PNG size tracks how complex the pixels are, not how small the source file was — and heavy JPEG compression leaves complex pixels behind. Encoding the same photograph across quality settings and converting each result in Chrome 153: quality 0.3 produced a 12.3 KB JPEG that became a 213 KB PNG, a 17.3× jump, while quality 0.95 produced a 187 KB JPEG that became 690 KB, only 3.7×. The multiple is worst for the most heavily compressed sources, and that PNG still carries every quality-0.3 artifact.

  • Expecting a server-side converter to produce the same picture

    PNG has no orientation tag, so EXIF rotation has to be resolved during conversion — and the defaults disagree. We built a 400×200 JPEG carrying EXIF Orientation=6 (display rotated 90°) and converted it several ways. Every browser applied the rotation and wrote an upright 200×400 PNG: Chrome 153, Firefox 155, and WebKit 26.6, both through createImageBitmap and through an img element. ImageMagick 7.1.2 and Pillow 12.3 both wrote 400×200 — sideways — until told to auto-orient explicitly. Same input file, two different pictures. A related surprise: passing imageOrientation: "none", which MDN documents as ignoring EXIF orientation, did not opt out in any of the three engines. The output was 200×400 either way, while a deliberately invalid value threw a TypeError and resizeWidth was honoured, so the option really was reaching the API.

  • Treating the browser PNG as the smallest possible PNG

    It is not, on two counts. A canvas created with default settings writes a 32-bit PNG whose alpha channel is 255 in every pixel; asking for an opaque context instead makes Chrome write a 24-bit PNG that is 12.2–17.3% smaller with bit-identical pixels across the four test images, which is what this converter now does (Firefox and WebKit emit the same bytes either way, so nothing is lost there). Beyond that, browser encoders are built for speed rather than density: re-encoding this tool's 549 KB photo output with Pillow at optimize=True produced 464 KB, 15.5% smaller and pixel for pixel identical. If bytes matter, run the download through oxipng or pngcrush.

  • Fearing the PNG step when the second JPEG save is what costs you

    Round-tripping the test photograph — JPEG quality 0.8, convert to PNG, save back to JPEG at the same quality — the PNG leg was exact (maximum per-channel difference 0) and the second JPEG encode shifted pixels by at most 5 out of 255, moving mean absolute error against the original from 2.9433 to 2.9440. One extra save at the same size and quality is very nearly free. What compounds is re-encoding with edits in between: when we measured resize-then-save loops with our image resizer, error kept growing with every pass instead of settling.

Frequently asked questions

Will the PNG be smaller than the JPG?+

No, and usually not by a little: across our four Chrome 153 test cases the PNG came out 3.6× to 9.6× the size of the JPG. PNG is lossless, so it stores every pixel the JPEG decoder handed it. For images with hard edges it can even exceed a PNG of the untouched original by 2.5–4.4×, because JPEG ringing adds noise PNG cannot compress. The benefit is transparency support and a format that will not degrade with further editing, not smaller files.

Is the JPG uploaded?+

No — conversion runs entirely in your browser using the Canvas API. Your image never leaves your device.

Does converting to PNG improve image quality?+

No. We diffed this tool's output against the decoded JPEG in three browser engines and found a maximum per-channel difference of 0 — the artifacts are copied exactly along with everything else. JPEG compression is already baked into the pixels. You gain a non-degrading format, not better quality.

Will the converted PNG come out rotated the right way?+

In a browser, yes. PNG cannot carry an orientation tag, so the rotation has to be baked into the pixels, and Chrome 153, Firefox 155, and WebKit 26.6 all did that automatically for a test JPEG marked EXIF Orientation=6 — a 400×200 file became an upright 200×400 PNG. Default server-side conversions do the opposite: ImageMagick and Pillow both dropped the tag without rotating unless explicitly told to auto-orient, so a browser conversion and a scripted one can disagree about which way is up.

Will the result have a transparent background?+

Not automatically. A JPG is fully opaque, so the PNG starts opaque too. The conversion makes transparency possible; you then erase or mask the background in an editor to create it.

When should I use this instead of compressing?+

Use it when a tool, store, or print service requires PNG, or when you need a lossless base for editing. If your goal is a smaller file, compress or convert to WebP instead.

Related tools

From the blog