PNG to WebP Converter

What this page documents

Every tool on this site is a thin interface over small, pure planning functions, and this page shows what those functions decide for one direction: a file whose bytes are PNG, re-encoded as WebP. The figures below — the detector's verdicts, the plan's flags, the plan's quality at each slider position, the output filenames, the size-change arithmetic — are not typed into the copy. They are computed at build time by the same engine code that runs when you drop a file, on illustrative inputs named as such, so if the engine changed, this page would change with it. The one exception is the pair of numbers at the slider's two ends, which are the range input's own minimum and maximum repeated from the control above — the engine exports no such bounds — and which are then fed to the planner so the plans at those ends are the engine's. The stages every converter here shares — createImageBitmap, orientation, the canvas draw, encoding, verification — are walked through end to end in the guide The conversion pipeline. This page covers what is specific to PNG in and WebP out.

What the detector sees

The first thing the tool does with a file is read its leading bytes and match them against the format signatures. A PNG begins with the 8 bytes 89 50 4E 47 0D 0A 1A 0A; passed exactly those bytes, detectFormat returns png. Passed only the first 7 of them it returns null — the signature must be complete, and a file matching none of the signatures is turned away with the formats this site reads named, rather than guessed at. The filename is consulted only afterwards, to compare its claim against the finding. An illustrative file named photo.png whose bytes begin FF D8 FF comes back from checkExtension as actual jpeg, claimed png, mismatch true; this page accepts PNG sources only, so that file's row names what it really is and points to the converter for that format. The reverse case is the useful one here: an illustrative file named sticker.webp that is actually PNG is detected as png (claimed webp), gets the visible mismatch notice, and is converted from the PNG it really is.

PNG is not one of the containers the engine treats as animatable — that list is GIF, WebP and AVIF sources, every one of which gets the plan flag; the visible per-file notice on an AVIF is driven separately by the avis image-sequence brand — so the plan for a PNG source sets its first-frame flag to false. The "only the first frame is converted" note that a GIF source would carry on this target (plan flag true) does not appear on this page, because nothing a PNG source can contain triggers it.

What the plan decides for PNG → WebP

Once the source is confirmed as PNG, planConversion('png', 'webp') produces the plan the client follows. Its full output on the defaults is:

Two of those fields are the whole character of this direction. The flatten flag is false because the capability table records WebP as able to hold an alpha channel (supportsAlpha: true). Compare the plan for the same PNG sent to JPEG, where the flag comes out true and the page has to ask for a background colour before converting; this page has no colour picker because the planner never calls for one. The quality field is a number rather than null because the same table marks WebP as lossy (lossy: true): the browser's canvas encoder for WebP takes a quality parameter. The client never leaves that parameter to the planner. On every lossy target it reads the slider's current value — resting at 85, which is the capability table's own default of 0.85 — divides it by one hundred, and passes the result explicitly, so a run on the untouched slider feeds the planner the same 0.85 the table above shows for a call with no options. The client falls back to the table's default only when the quality input is missing from the form or its value is not a finite number; the planner then validates whatever it is handed.

The output filename is derived by swapping the extension for the target's canonical one, .webp, and preserving the stem. Illustratively: logo.png becomes logo.webp; Screenshot 2026-05-01.PNG becomes Screenshot 2026-05-01.webp; icons.v2.png keeps its inner dot and becomes icons.v2.webp. The one case that earns a suffix is the misnamed file from the previous section: sticker.webp, really PNG, would otherwise produce a download with its own name, so the planner names the output sticker-converted.webp.

The quality parameter, exactly

The slider above runs from 5 to 95 — the range input's own bounds, repeated here from the control rather than read from the engine, which exports none — and starts at 85. The client divides its value by one hundred, clamps the result to that same range, and hands it to the planner, which validates it again before any pixel is touched. At 60 the plan's quality is 0.6; at the slider's two ends it is 0.05 and 0.95. The planner's own acceptance range is wider than the slider's, and it refuses rather than guesses outside it — an engine-level check the slider can never trip, since the client clamps first. Asked directly for a quality of 1.5 it answers "Quality must be between 0.05 and 1.", and asked to apply a quality to a lossless target it answers "This output format is lossless and has no quality setting.". Both messages are the engine's own, reproduced here at build time.

What the number is not is a prediction of file size, or a percentage of anything about your image. It is the parameter the browser's WebP encoder accepts; how many bytes result depends on the picture's content and is known only after encoding, which is why the result row reports a measured byte count instead of an estimate. Nor is there a lossless position on the slider. The engine's capability table records WebP as lossy (lossy: true) because the canvas toBlob call this tool uses produces lossy WebP; the engine's own note on that entry records that the format also has a lossless mode which that call does not expose. So every output of this page is lossy WebP, and the page does not pretend otherwise. If bit-exact pixels are the requirement, the honest answer is to keep the PNG, and to reduce its dimensions with the Image Resizer if size is the problem.

The encoder on this lane

This direction uses no vendored codec. Decoding is the browser's own, through createImageBitmap with imageOrientation: 'from-image'; the pixels are drawn to a canvas with no background fill, because the plan said none was needed; and the canvas is encoded by the browser's built-in WebP encoder, given the plan's image/webp type and quality. The two self-hosted encoders on this site — MozJPEG on the Compress JPEG lane and libavif + aom for AVIF output — are not involved, so there is no module to fetch and nothing to attribute beyond the browser itself. The consequence is that the encoder is the browser's to provide, not the site's. A browser that cannot encode WebP may silently substitute PNG, and that is precisely the case the verification step below exists to catch — it is reported as an honest error, never as a mislabelled file.

What re-encoding strips — and what survives

Canvas re-encoding strips all embedded metadata: EXIF (including GPS location, camera model, and timestamps), colour-profile tags, and text chunks. For a PNG source the practical reading is that whatever the file carried alongside its pixels — profile tags, text chunks, anything embedded by the tool that made it — is not in the WebP. That is both a feature and a caveat: a published conversion cannot leak what the original carried, and equally the original is the only copy that still has it, so keep it. Orientation is applied during decoding, before the metadata is discarded, so an image that depended on an orientation tag comes out upright even though the tag itself is gone. What survives is what the pipeline preserves and the verifier checks: the full pixel grid at the source dimensions, and the alpha channel, because supportsAlpha is true for this target and no flattening step ran.

How the output is verified

A download button on this page means the output has already been checked three ways. First, the produced bytes are sniffed with the same detector applied to inputs. A WebP begins RIFF, four size bytes, WEBP; on a header built that way detectFormat returns webp, which is what the verifier expects. Had the browser substituted PNG, the detector would return png on the output's leading bytes, the expectation would fail, and the row would show an error naming what was produced — never a .webp file containing PNG. Second, the blob is re-decoded and its pixel dimensions compared with the canvas it came from; a mismatch is reported as a verification failure. Third, the size shown is the output blob's true byte count, printed beside the input's.

Where the row shows a percent change, it is computed from those two measured counts by describeSizeChange and nothing else. The rounding is the engine's, shown here on invented byte counts, not on any real image: 1,048,576 bytes becoming 262,144 reads "75% smaller"; 4,096 becoming 4,480 reads "9.4% larger — keep your original", keeping one decimal place; 1,000,000 becoming 950,000 reads "5% smaller", the trailing zero dropped; from "10% smaller" upward the figure is a whole number, and 10,000 becoming 9,004 lands there because the threshold is applied to the already-rounded figure; and a change too small to round to a tenth of a percent — 100,000 becoming 99,990 — reads "less than 0.1% smaller". The site publishes no blanket compression percentages anywhere, because no percentage is true for every image, and a result that comes out larger is stated as plainly as one that comes out smaller.

What the tool cannot know

The engine decides everything that can be decided from formats, filenames, and numbers, and nothing else. It cannot know whether the lossy approximation at a given quality is acceptable for your image — that depends on what the image is for, and the tool makes no visual-quality judgement at any slider position. It cannot know before encoding whether the WebP will be smaller than the PNG; it finds out by encoding, and tells you, including when the answer is "larger — keep your original". It cannot know whether the place you are sending the file accepts WebP; that is the destination's rule, and if the destination refuses, PNG to JPG or the original PNG are the alternatives. And it cannot add anything the PNG did not contain: the WebP has exactly the source's pixel dimensions, and the Image Resizer is the tool for changing those.

Common misreadings

• "WebP is lossless, like PNG, so nothing is lost." Not from a canvas. The plan's quality field is 0.85 by default, not null; the output is lossy WebP at every slider position.
• "Quality 85 means 85% of the original." The number is the encoder's parameter on a 0–1 scale, shown multiplied by one hundred. It does not measure fidelity against the source and does not predict size.
• "My transparent areas will get a white background." Not on this pair: needsBackgroundFlatten is false, and the #ffffff the planner records is never applied. Flattening happens on the JPEG direction, which asks for the colour first.
• "The file got bigger, so the conversion failed." It succeeded and was verified; the row reports the measured growth and recommends the original. Whether a PNG re-encodes smaller is a property of that image, learned by measuring it.
• "The tool converts whatever my filename says." It converts what the bytes are. A .png that is really JPEG is turned away from this page with its real format named; a .webp that is really PNG is converted from PNG, with a notice, to sticker-converted.webp.
• "Metadata comes along for the ride." It does not. Orientation is honoured in the pixels, and everything else embedded in the PNG stays with the PNG.
• "Only the first frame will be kept." That plan flag belongs to GIF, WebP and AVIF sources, and the per-file notice to files the animation check actually flags — an AVIF declaring the avis brand among them. For a PNG source the plan's flag is false.

Related tools and guides

The guide The conversion pipeline walks the shared stages — decode, orientation, canvas, encode, verify — with the plans for several format pairs side by side, and the guides index covers detection, transparency, quality parameters, and metadata in their own pages. Unwrapping WebP back into PNG is WebP to PNG. Photographs headed to WebP that start life as JPG belong on JPG to WebP. To chase a specific file-size ceiling in KB, use the Image Compressor's target-size mode, which searches the quality range by measurement rather than prediction.

Frequently asked questions

Local processing: conversion, verification, and downloads are all generated inside your browser — nothing is transmitted. See the methodology page to verify.