JPG to PNG: compatibility without false promises
Choose the output for the application that will use it. This guide explains the settings, the limits and the checks that turn a completed conversion into a usable file.
In this guide +
Use PNG for compatibility or a lossless working copy
Convert JPG to PNG when an editor or delivery specification requires PNG, or when you want to store the decoded working pixels without another lossy export at this step. This creates a real PNG at the supported visible dimensions. It does not improve the camera source, increase resolution or remove existing JPEG artifacts.
JPG and JPEG are accepted names for the same source format. The output uses .png because the actual data is PNG-encoded. Merely renaming a JPEG would leave JPEG bytes inside the file. Keep both source and result until the PNG has opened successfully in the intended application.
A PNG extension cannot make a JPEG background transparent
A JPEG contains opaque pixels. When converted to PNG, those pixels remain opaque, including a white studio background or a checkerboard painted into the photo. PNG’s ability to store alpha is a capability of the format, not an instruction to identify the subject or delete surrounding pixels.
If your goal is a cutout, remove the background in an editor and export a file with a genuine alpha channel. If your goal is a form that requires PNG, an opaque PNG may be exactly what you need. Distinguish the two tasks before spending time repeating a conversion that cannot change the background.
JPEG opacity → stays opaque in PNG → background removal requires a separate editing step.
Expect a different file size, without a PNG quality slider
PNG stores the working pixel grid losslessly. A photographic JPEG often stores that scene much more compactly with lossy compression, so the PNG can be substantially larger at the same dimensions. This increase is not a gain in useful image detail. It reflects a different way of storing the decoded image.
There is no lossy PNG quality setting in this tool. If the destination requires PNG below a strict cap, a separate resize or PNG optimization step may be needed. If PNG is optional and byte size is the priority, compare the original JPEG or a JPG to WebP delivery instead of assuming PNG is better.
Dimensions, orientation and the size of the preview
Changing the format does not resize or crop the image. A 2400 × 1600 landscape stays at that pixel size. An orientation tag can require a rotation or a reflection; when a portrait is rotated into its visible orientation, width and height may exchange places. That is an orientation correction, not a reduction in resolution.
The preview is fitted to the available space and can use a smaller display copy. Judge output dimensions from the downloaded file, not from how large it appears on your screen. For print work, also check the required physical size and resolution in your design application; a format conversion does not prepare a complete print specification.
EXIF, GPS, color profiles and what is not preserved
The output is a newly encoded image. Original EXIF, GPS and XMP records are not copied; an encoder may add its own technical fields. Orientation is applied to the image rather than relying on the original orientation tag in the download. Keep the original if you need camera settings, capture dates or an archival record.
Working pixels use an sRGB canvas where supported. Exact source ICC profiles, HDR information and 16-bit precision are not retained. A screen that looks similar is not proof of identical color data. For calibrated print, scientific measurement or preservation of high-bit-depth originals, use a workflow designed for those requirements.
The limits before you start
The converter accepts still images within all of the limits below. They are admission limits, not performance promises. A queue can be accepted and later produce a larger result that cannot be retained or packed into one archive. Save individual completed files when a ZIP is unavailable.
MiB means 1,048,576 bytes. A ZIP also has a working-memory limit, so the byte cap alone does not determine availability.
| Resource | Maximum |
|---|---|
| Files in one queue | 10 |
| Each source file | 20 MiB |
| Total source / total retained results | 100 MiB / 100 MiB |
| Pixels in each image | 16,000,000 |
| Width or height | 8192 px |
| ZIP download | 64 MiB; 32 MiB in smaller-limit mode |
Why a small file can still need substantial memory
Encoded file size and working memory measure different things. A 4000 × 3000 image contains 12 million pixels. One ordinary RGBA buffer uses four bytes per pixel: 48,000,000 bytes, or about 45.8 MiB. Decoding, previewing, encoding and retaining the result can need additional buffers. This calculation is a baseline, not a measured peak.
That is why a compressed file below the byte limit may still exceed the pixel limit. Start with one large image on a phone, save it, then clear the queue before the next group. Closing other heavy tabs can help, but passing a limit check does not guarantee that every device has enough memory to finish.
Local processing: what stays on your device
Selecting a file gives this page access to the selected image so it can decode and convert it in your browser. Source files, filenames, pixels, previews, EXIF and clipboard images are not sent to a conversion server or telemetry by this tool. ZIP creation also runs on the device. No account is required.
Local image processing does not mean that opening the website makes no network requests. The browser still requests the page, scripts and codec assets, and the host can receive ordinary connection information. Cookie Settings describes the available optional purposes and lets you change your choice. Keep sensitive downloads under your own device and storage controls.
Troubleshooting by symptom
Read the specific message before changing settings. A wrong format, an animated input and a memory limit need different fixes. Renaming a rejected file or repeatedly clicking Convert does not address the cause. Save completed results before clearing or reloading a queue.
| Symptom | What to check | Try this |
|---|---|---|
| File rejected | Actual format, animation, bytes and dimensions | Choose the matching tool and a supported still image |
| Conversion stops | Device memory or a decode/encode error | Retry once with one file; use a smaller source if needed |
| ZIP unavailable | Archive byte cap and memory budget | Download individually or split the group |
| Background remains | Opaque pixels rather than alpha | Use an image editor if background removal is needed |
| Page works, tool does not | JavaScript, blocked assets or browser support | Allow required site assets and try a current browser |
A practical check before you use the result
A successful download is the start of the final check. Open the output in the application that will actually use it. A slide editor, upload form and image viewer can handle the same file differently. Checking the intended destination catches problems that the browser preview alone cannot reveal.
- Confirm the extension and that the destination opens the image without an error.
- Check width, height and visible orientation; compare them with the original.
- Inspect fine text, diagonals, hair, shadows and gradients at 100% zoom.
- Place transparent graphics on both a light and a dark background.
- Compare the actual byte size with the destination limit before submitting.
- Keep the source until every downloaded file has been checked.