PNG to WebP: transparency with a smaller delivery in mind
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 +
WebP delivery from a PNG master
Use PNG to WebP to create a delivery copy for a website or app that accepts WebP. It can be a useful choice for a product cutout, interface illustration or graphic with transparency. Keep the PNG master and judge the WebP by its actual appearance and size rather than assuming that a new format must be smaller.
The WebP format supports several modes, but this converter exports lossy color with preserved alpha. It does not expose a lossless WebP mode. A quality setting of 100 still does not turn this export into a promise of lossless color. If exact working pixels are required, retain the PNG rather than treating a high quality number as a substitute.
PNG pixels → lossy WebP color encoding + alpha → a delivery copy that needs visual comparison.
Reference: Google: WebP compression
Transparency: what the checkerboard really means
Transparency is information attached to pixels, not a white background that the converter can recognize and erase. A transparent logo can sit over a presentation, a colored product card or a dark website without bringing a rectangular backdrop with it. An opaque white pixel stays white after conversion.
The preview uses a checkerboard to make empty and partially transparent areas visible. The pattern belongs to the interface and is not added to the downloaded image. After downloading, place the result on both a light and a dark background. This reveals pale fringes, baked-in backgrounds and edges that a white preview can hide.
Alpha channel → controls pixel opacity → allows the background underneath to show through.

Reference: W3C: PNG specification
Use quality as a comparison setting, not a percentage of detail
The default quality is 82, with presets at 92, 82 and 65 and a custom control. These values are encoder settings. A value of 82 does not mean that 82% of the original detail survives, nor does it promise a particular file size. Content and the active encoder affect the visible result and the byte count.
Make a comparison from the same source at two settings. Check small text, sharp edges, hair, texture and gradients at the size you will actually use. Prefer the smaller output only if the visible change is acceptable. A higher setting cannot restore detail already discarded in the source, and settings from different formats are not directly equivalent.
What to inspect in transparent graphics
Compare flat brand colors, small text and sharp diagonals. These features may reveal compression changes more clearly than a photograph. Test a transparent asset on the actual light and dark backgrounds where it will appear; preserving alpha does not mean preserving every color sample at the edge.
For screenshot documentation, readability takes priority over a small download. Start at the default setting, compare a higher setting when needed and retain PNG if the WebP is visibly unsuitable. A batch should use settings validated on representative graphics, not only on the easiest image in the collection.
Check the place where the WebP will be used
A WebP that opens in your browser still needs to be accepted by the destination workflow. Test the actual CMS, upload form, image editor or app before converting an entire collection. A system may accept the file yet generate its own thumbnails or transform it again, so inspect the published result as well as the local download.
If a website needs responsive images, alternative formats or a smaller display dimension, those delivery decisions happen outside this converter. The tool preserves the source dimensions and exports one still WebP per image. Keep your original PNG or JPG as the master, and create a separate WebP delivery copy rather than replacing your only source.
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.