WebP to PNG Converter

What the detector sees in a .webp file

The first thing this tool does with a file is read its leading bytes and compare them with the format signatures the methodology page lists. A WebP is recognised by two ASCII markers in fixed positions: RIFF at the start and WEBP 8 bytes in — the RIFF…WEBP signature. The 4 bytes between them hold a length the detector does not read, and the verdict is complete within the first 12 bytes: a header constructed here of the bare signature and nothing after it is returned as WebP, while one with WEBP written directly after RIFF, 4 bytes early, is unrecognized. Run at build time on three further headers constructed here — one whose first chunk is a plain VP8 bitstream, one whose first chunk is VP8X with a flags byte of 10, and one whose VP8X flags byte is 12 — the detector returns WebP, WebP and WebP. The chunk that follows the signature does not change the verdict; it is read by a second check, described below. Handed the 8-byte PNG signature instead, the same detector returns PNG.

The filename is compared with that verdict, never trusted over it. The illustrative header paired with the name banner.webp reports a mismatch of no, and conversion proceeds without comment. Paired with banner.png, the same bytes are WebP while the extension claims PNG — mismatch yes — and this page converts from the actual WebP content with a notice on the row. A name with no extension, IMG_0001, claims nothing, so the check reports no mismatch (no) and the bytes alone decide. The reverse case matters too, because this page accepts WebP sources only: banner.webp whose bytes begin FF D8 FF is reported as JPEG, and the row names that format and links to the converter for it rather than converting under a false label; banner.webp whose bytes are the PNG signature is reported as PNG — already what this page produces, so there is nothing to convert.

The plan for this pair

Every decision the tool makes is taken by a pure planning function from two inputs: the detected source format and the target. There are no controls on this page to add a third. Asked at build time to plan WebP into PNG, the function returns the MIME type image/png; flatten onto a background: no; encode quality: null, meaning the encoder is given none; and animation dropping to the first frame: yes. Each field follows from the engine's capability table for PNG output — can it carry per-pixel transparency: yes; does its encoder take a quality parameter: no; default quality: null — combined with the fact that WebP is a container the engine lists as able to hold both alpha and animation.

The two fields a control could change are closed on this page, and the planner enforces that rather than leaving it to the interface. Asked at build time, with an illustrative quality of 0.8, to plan the same pair, it refuses: "This output format is lossless and has no quality setting." Asked to plan it with an illustrative background of #000000, it accepts the colour — the plan records #000000 — but the flatten flag stays no, so the colour is never painted. That is why the page shows no quality slider and no colour picker: there is no field in the plan for either to move. For contrast, the plan for the same WebP into JPEG — the WebP to JPG page — carries the MIME type image/jpeg and sets flatten to yes and quality to 0.92, because JPEG output can hold alpha: no. Compared field by field at build time, the two plans differ in 4 places — target, mime, needsBackgroundFlatten, quality: the target and its MIME type differ by definition, and the two fields a control could move — flatten and quality — are what separate that plan from this one.

Transparency is kept, not flattened

Because the flatten flag is no, the canvas receives the decoded WebP with no fill painted first. A semi-transparent pixel keeps its alpha, and the PNG encoder writes that alpha channel into the file — nothing is composited onto a background, and PNG output holds it. Nothing on this page asks for a background colour and no file row reports one, in contrast to the JPEG page, where every row records the colour that was composited. One consequence is worth stating plainly: the decision is made from the format pair, not by scanning pixels, so the tool does not know whether your particular WebP has a transparent pixel in it. An opaque photograph and a cut-out logo take the identical plan; the photograph simply has nothing in its alpha channel to preserve. The Transparency and flattening guide covers the same decision for every output format the site produces.

Decode, draw, encode — the browser's codecs only

Decoding uses the browser's own codec through createImageBitmap with imageOrientation: 'from-image', so any rotation recorded in the file is applied to the pixels during decoding. The bitmap is drawn onto a canvas at its own dimensions, and the canvas is encoded by the browser's built-in PNG encoder with the plan's MIME type, image/png, and no quality argument. Nothing is vendored on this lane. The site's two self-hosted encoders — MozJPEG on the Compress JPEG lane and libavif + aom for AVIF output — are not involved, and neither is the libheif decoder that only the two HEIC pages load. Decoder and encoder are both the browser's; the site's own code decides the plan, draws the canvas and verifies the result.

The plan takes the format, not the file. A WebP may have been saved by a lossy or a lossless encoder — the format has both modes — and the planner does not consult which, so the two kinds of file receive the same plan and pass through the same stages. From decode onward nothing further is lost in either case: PNG output is lossless in the capability table, and the file stores the canvas pixels exactly. What the conversion cannot do is reach back before the decode. Whatever a lossy WebP encoder discarded when the file was first saved is not in the file, and no conversion can put it back; the PNG preserves exactly what was there, no more. The tool makes no measurement of how much that was and claims none.

Animation: first frame only, flagged per file

The plan's first-frame flag is yes for every WebP source, because the container can hold animation and canvas decoding keeps one frame; PNG is a still-image format and this tool does not produce APNG. Whether a given row carries the notice is decided by a separate per-file check that walks the RIFF chunk list of the leading bytes, looking for a VP8X chunk whose flags byte has the animation bit set, or for an ANIM or ANMF chunk. Run at build time on the constructed headers: the plain VP8 still reports no; the VP8X header with flags 10 reports no; the header with flags 12 reports yes; and a still-flagged VP8X followed by an ANIM chunk reports yes. When the answer is yes, the row says so before the download appears, so no frame is discarded silently. The check is WebP-specific and conservative: on the PNG signature it reports no without looking further.

What re-encoding strips

The PNG that comes out is a fresh encode of pixels, not an edit of the WebP's bytes, so none of the WebP's embedded metadata travels with it. EXIF — including GPS location, camera model and timestamps — colour-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 image cannot leak where it was taken, and equally a photographer loses copyright fields and the embedded profile, so keep the original. Orientation is the one field handled before it is discarded: it is applied during decoding, so the PNG comes out upright even though no orientation tag survives to say so. The metadata guide covers the same facts for every lane on the site.

How the output is verified and named

A download button on this page means the output has already been checked. The encoder's bytes are treated like a stranger's file: their leading bytes are sniffed with the same detector that read the input and must identify as PNG, which catches a browser that quietly wrote some other format; then the blob is decoded again and its pixel dimensions compared with the canvas that produced it. A file that will not decode, or a dimension that disagrees, is reported as an error on the row — never offered as a mislabeled download. The size shown beside the verified badge is the output blob's true byte count, and dimensions are not changed here: the PNG has exactly the pixel size of the decoded WebP, which the verification confirms.

The filename rule belongs to the same planning module. It keeps the stem, swaps the extension for the target's canonical one — png — and appends -converted only when the result would otherwise carry the input's own name. Computed at build time on invented names:

The upper-case extension is replaced because the comparison is case-insensitive and the output extension is always written the same way; the inner dot in sticker.v2.webp is part of the stem and survives; a name with no extension simply gains one. The suffix appears on this page in exactly one situation — a file named .png whose bytes were WebP — because that is the only way a WebP source can arrive already carrying the output's extension.

"PNG grows" — measured, never predicted

The about page's shorthand for PNG output is "PNG grows", and it is a shorthand, not a figure. The percentage on a row is computed from the two true byte counts for your file and nothing else; a result that comes out larger is labelled "larger — keep your original" in the same breath as a smaller one would be reported. To show the wording without implying an expectation, here is the arithmetic on invented numbers that are not predictions for any real file: a 96,000-byte WebP becoming a 412,000-byte PNG reads "329% larger — keep your original"; the same input becoming 104,000 bytes reads "8.3% larger — keep your original"; becoming 71,000 bytes reads "26% smaller". The site publishes no blanket compression percentage anywhere, because no percentage is true for every image. A file that has to land under a given size belongs on the Image Compressor, whose compress-to-target search converts a PNG input to a lossy format and labels it as such.

What the tool cannot know

The verification checks format and dimensions; it does not look at the picture. The tool cannot tell you whether the WebP you dropped was saved lossy or lossless, how much detail a lossy save discarded, or what the image looks like — it measures bytes and dimensions and reports those. It cannot tell you whether your WebP contained a transparent pixel, because the plan never scans for one. It does not know the destination either: whether the place the PNG is going accepts PNG, has a size limit, or needs smaller dimensions is for you to check, and the Image Resizer is the page for the last of those.

Common misreadings

• "Lossless means the PNG is better than the WebP." It means nothing further is lost after decode. The PNG holds exactly the pixels the decoder produced; it cannot hold detail the WebP never had.
• "The PNG is bigger, so something went wrong." Nothing went wrong. The row reported the measured result and labelled it; "8.3% larger — keep your original" is a report, not an error.
• "It ends in .webp, so it is a WebP." Only the bytes decide. The illustrative banner.webp whose bytes begin FF D8 FF is reported as JPEG, not converted as WebP.
• "My animated WebP converted, so the PNG animates." It does not. The first-frame flag is yes for every WebP source, and the row flags the file when the per-file check finds the animation flag or an ANIM chunk.
• "There is no background picker, so transparency must be lost." The opposite: there is no picker because the flatten flag is no and the alpha channel is written into the PNG.
• "The missing quality slider is an oversight." The planner refuses a quality for PNG output — "This output format is lossless and has no quality setting." — so there is nothing for a slider to set.
• "Converting to PNG keeps my photo's EXIF." It does not. Re-encoding strips all embedded metadata; only the effect of the orientation tag survives, applied to the pixels before the tag is discarded.

Limits on this page

Inputs are limited to 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection, in the terms the methodology page states; a file over the per-file limits is reported on its own row. Files within a selection are processed one after another. Nothing is resized, cropped or edited — the output is the decoded image at its own dimensions, re-encoded — so an image that also needs to be smaller in pixels should also go through the Image Resizer.

Related tools and guides

Need a smaller file rather than a lossless one? WebP to JPG plans the same source into a target that cannot hold alpha and takes a quality parameter, so the two fields this page holds closed — flatten and quality — are set there. Going the other way, PNG to WebP re-encodes PNGs as WebP. To shrink without changing format, use the Image Compressor; to change dimensions, the Image Resizer. For the detector that opens every conversion here, read How image formats are detected; The conversion pipeline follows the same stages for several pairs, and all the guides are indexed together.

Frequently asked questions

Local processing: files are decoded, converted, and verified entirely in your browser and never transmitted. How that is enforced — and how to check it yourself — is on the methodology page.