Compress an image to WebP: 37% more pixels for the same 100 KB

Take one 3,492,678-byte photograph measuring 4000 × 6000 — 24.00 megapixels — and ask this site's compressor for 100 KB twice. As JPG it comes back at 1,031 × 1,547, which is 1.60 megapixels. As WebP it comes back at 1,209 × 1,814, which is 2.19 megapixels. Same source, same ceiling, same 40% quality floor underneath both: 37.5% more pixels survived in WebP, for 187 bytes more.

That 37.5% is not a property of the format. On the same photograph at 300 KB the two settings land 60.9% apart; on a scanned page at 100 KB the gap collapses to 4.4%; on a cut-out with a transparent background the gain stops being pixels at all — WebP kept the transparency and spent 49,862 bytes, while JPG spent 102,064 and painted the background white. Converting to WebP buys one of three different things depending on your budget and your picture, and the first job is to know which.

Test conditions: Chrome 155.0.8059.85 on Windows 11, this site's compressor served from a local copy on 127.0.0.1:8765, one file at a time through the normal file input, no upload. Nine source files, 30 compressor runs (14 for the byte ladder, 14 for the file-type table, 2 for the fill-point search) and 24 fixed-quality encodes. Output bytes are read twice: once from the page's own report object and once by fetching the produced blob and reading arrayBuffer().byteLength — the two agreed on every row. Output dimensions are read by decoding the produced data URL back into an Image and taking naturalWidth and naturalHeight, not from the numbers the tool printed, and they matched on every row. "Quality" is the encoder setting the tool's search settled on, reported as a percentage. Times are the tool's own Done in N ms value, which varies run to run on this 4 GB machine; treat the ratio between formats as the finding and the individual seconds as an illustration.

Six byte targets, two encoders, one 24-megapixel photograph

Each pair below is the same source file, the same target, the same tool, with only the output format changed. Both outputs land within 0.6% of each other in bytes, so this is a comparison at an equal ceiling rather than "WebP made a smaller file".

Read the quality column first, because it explains the pixel column. From 20 KB to 300 KB every JPG output is pinned at 40.47% and every WebP output sits between 40.00% and 40.94% — that is the tool's floor, the point below which it stops lowering quality and starts removing pixels instead. With quality held constant by that floor, the only remaining variable is how many pixels each encoder can fit under the ceiling, and WebP fits more: 39.4% more at 20 KB, 37.5% at 100 KB, 60.9% at 300 KB.

The 300 KB row is the one that surprises people, because the gain widens instead of shrinking. Nothing about the format changed between the 100 KB and 300 KB rows; what changed is the scale step each search landed on. At 100 KB the two searches stopped at 1,031 and 1,209 pixels wide, close together. At 300 KB the JPG search stopped at 1,796 while the WebP search reached 2,278. A search that has to step down in resolution cannot land on a fraction of a step, so the ratios are lumpy by construction. That is why the honest statement is a range — 37% to 61% between 20 KB and 300 KB — and not the single number in the headline.

The 1000 KB row is where the shape of the comparison changes, and the next section is about that row.

The fill point: where the advantage stops being pixels

At 1000 KB the JPG output is still being cut: 3,577 × 5,365 is 19.19 MP, 80% of the frame, at 40.47% quality. The WebP output at the same ceiling holds the whole 4000 × 6000 frame and spends its remaining budget on quality, landing at 60.16%. So at 1 MB the two formats are no longer answering the same question — one is choosing which pixels to throw away, the other is choosing how good the pixels should look.

Where each format crosses that point is measurable on the same file, and the two answers are far apart. At a 600 KB target WebP was still cutting — 3,673 × 5,510 = 20.24 MP, 84.3% of the frame, at 40.00% — and at 1000 KB it held all 24.00 MP at 60.16%. JPG had not reached the full frame at 1000 KB (19.19 MP) and only did at 2000 KB (24.00 MP, 70.47%). So on this photograph the two formats cross the fill point more than 1,000 KB apart: WebP arrives there at 1,000 KB or below, JPG needs 2,000 KB in this ladder.

The gap widens on bigger sources, because the fill point is further away and both formats spend longer in pixel-cutting mode. On an 11,525,365-byte photograph measuring 6000 × 9000 — 54 megapixels — at a 1000 KB target, JPG returned 3,551 × 5,326 = 18.91 MP at 40.47%, and WebP returned 5,232 × 7,848 = 41.06 MP at the same 40.47%. That is 2.17× the pixels for 1,016,922 bytes against 1,018,551 — and 2.54× the time, 105,868 ms against 41,711 ms. If you are compressing a phone photo of 12 MP or less, you will mostly live below the fill point and the pixel gains are what you get. If you are working from a 24 MP camera file, the fill point is where the decision actually is.

It is not 37% for everything: seven file types at 100 KB

Same tool, same 100 KB target, same day, seven different pictures. The pixel column is what the search returned; where both formats held the full frame, the difference shows up in the quality column instead.

The scan is the weakest case in the table and the most useful one, because it is the case people expect to win. A page of black text on white paper compresses extremely well in JPEG — most 8×8 blocks are flat — so at 100 KB the JPG search still held 675 × 1,013, and WebP's 690 × 1,035 is 4.4% more pixels and 8 quality points. Four percent is not a reason to change your workflow. The same applies to the small photo: 1,000 × 1,500 against 998 × 1,497 is a rounding difference, and the quality gap is under four points.

Flat art and transparency are the opposite extreme. The 16.00 MP graphic is 84,394 bytes as a PNG, which is small — but as JPG at a 100 KB target it needed 101,300 bytes and still had to cut down to 3,139 × 3,139 = 9.85 MP at 40.47% quality. WebP held all 16.00 MP at 99.53% and used 89,376 bytes, fewer bytes than the JPG output. Sharp edges and large flat areas are where the two encoders differ most, and it is not a small difference.

Transparency is a channel, not a quality setting

The cut-out in the table is 3,600 × 3,600 with 71.91% of its pixels fully transparent — measured by resampling both the source and the output to a 900 × 900 grid and counting alpha below 64. The two outputs at a 100 KB target:

This is the tool behaving correctly rather than a bug: JPEG has no alpha channel, so before drawing, the canvas is filled with white and the transparent regions become white pixels. The cost is double. You lose the cut-out, and you pay for the white — the JPG output is 102,064 bytes, more than twice the WebP output and still 64.4% more than the 62,081-byte PNG it started from. The WebP output, by contrast, is 19.7% smaller than the source PNG with the transparency intact. For a logo, a product cut-out or anything destined to sit on a coloured background, converting to WebP is not an optimisation you weigh up — it is the only lossy format in this tool that leaves the file usable.

If the file is a cut-out and you would rather stay lossless, the PNG side of this problem — how far a PNG can be pushed before it has to give up pixels — is measured on the 100 KB PNG page. The two answers differ: PNG has no quality dial, so at a fixed byte target the only lever is resolution.

Google says 25–34% smaller. Re-measured: 27.9% at q90, 43.0% at q75

Google's own page states it plainly: "WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index" (developers.google.com/speed/webp, the sentence directly under the page heading "An image format for the Web", read 29 October 2026). That is a claim about bytes at equal quality. The 37.5% at the top of this page is a claim about pixels at equal bytes. They are different measurements, and this page does not convert one into the other — the sampling point is different, and a ratio built from two different sampling points is not a ratio of anything.

So the claim was re-measured on its own terms: full frame, no target search, no tool involved, just the browser's encoder at a fixed quality, once as JPG and once as WebP.

On the one file in the set that is a real photograph, q0.90 gives 27.9% — inside the published 25–34% band — and q0.75 gives 43.0%, outside it. The band is real but it is a band at a particular quality setting, and quality settings are not portable across encoders: q0.75 in this browser's JPEG encoder is not the same picture as q0.75 in its WebP encoder. What survives across both framings is the direction and the rough size: on a photograph, expect tens of percent, not multiples; on flat art and transparency, expect multiples. The gradient row is the extreme — 86.6% smaller at q0.75 — and it is the row least like a photograph.

Two cases where converting to WebP makes things worse

The file was already small enough. The 16.00 MP flat graphic is 84,394 bytes as a PNG. At a 100 KB target it does not need compressing at all — and both conversions made it bigger: 89,376 bytes as WebP (+5.9%) and 101,300 bytes as JPG (+20.1%). This tool passes a file through untouched only when it is already under the target and already in the requested format, so switching the format selector forces a full re-encode of a file that had nothing to gain. If your file is under the limit and the limit is all you care about, stop — do not convert it.

The seconds are the constraint, not the bytes. On this machine WebP took longer in every pair. At 300 KB it was 27,722 ms against 5,067 ms; on the 54 MP file at 1 MB it was 105,868 ms against 41,711 ms. For one file that is nothing. For a folder of forty phone photos on a laptop, it is the difference between a coffee and an afternoon, and the pixel gain on a 12 MP photo below its fill point does not always justify it.

There is a third case that is not about numbers at all: the place you are sending the file. Many upload forms accept a fixed list of extensions, and a .webp outside that list is refused for the extension before any size check runs. This page does not print other companies' accept lists, because a limit that cannot be read on the owner's own page is not a number worth publishing — check the form's accept list, or send one test file, before converting a batch.

Running it in this tool

1. Drop the file and read the two numbers first. The panel prints bytes and pixels, for example 3.3 MB · 4000 × 6000 px, before you press anything. If the byte count is already under your limit and the format is already accepted, you are done — see the section above.
2. Pick WebP in the format row. The hint under the row changes with the format, because PNG behaves differently: it is lossless, so the only lever there is resolution.
3. Type the ceiling in KB. The field multiplies by 1024, so 100 KB means 102,400 bytes. If the limit you were given is a strict decimal number — 100,000 bytes, not 102,400 — type 97 instead; the arithmetic behind that is on the 1953 KB page.
4. Read the result panel, not just the size. It prints bytes, output dimensions and format. The dimensions are the number that tells you whether the budget was spent on pixels or on quality — if they did not move, you were above the fill point and WebP bought you quality instead.
5. If the dimensions dropped and you needed them, raise the budget. Lowering the quality setting is not an option the tool offers, and that is deliberate: below 40% the encoder shrinks the picture instead, which looks better at the same file size.

The pixel budget for a specific ceiling is measured per target on 300 KB (4.84 MP in JPG), 500 KB (8.41 MP) and 1 MB (19.75 MP kept whole). Every one of those numbers is for JPG, and this page is the reason they do not carry over: the same ceiling in WebP returns a different pixel count.

Questions this measurement answers

Does converting to WebP make the file smaller at the same quality?

Yes, and the size of the gain depends on the picture. At a fixed quality of 0.90 the 24 MP photograph went from 3,798,606 bytes to 2,739,646 — 27.9% smaller. At 0.75 the same file went from 2,225,485 to 1,267,766 — 43.0% smaller. On the flat graphic at 0.90 it went from 226,258 to 75,298, which is 66.7%.

How many more pixels does WebP keep at the same file size?

On a 24 MP photo at 100 KB: 2.19 MP against 1.60 MP, or 37.5% more. At 300 KB: 60.9% more. At 100 KB on a scanned page: 4.4% more. The percentage is a property of the picture, so the useful version of the question is "how much does it buy on this file", which is one run of the tool away.

Will WebP keep a transparent background?

Yes. On a cut-out where 71.91% of pixels were fully transparent, 100% of them stayed transparent in the WebP output, at 49,862 bytes. JPG kept none of them and used 102,064 bytes, because JPEG has no alpha channel and the canvas is filled white before drawing.

Why did my WebP file get bigger than the original?

Because the original was already well compressed. Measured: an 84,394-byte PNG at a 100 KB target came back at 89,376 bytes as WebP and 101,300 bytes as JPG. A format change is a re-encode, and a re-encode of a file that already fits can only add bytes.

Is WebP always slower to produce?

In all six pairs measured, yes — between 1.2× and 5.5×. The single worst case was a 300 KB target on the 24 MP photo at 27,722 ms against 5,067 ms. The absolute numbers move run to run on a small machine; the ratio was consistent in direction every time.

The boundary this page can defend, measured: at a 100 KB ceiling, the same 24-megapixel photograph returned 1.60 MP as JPG and 2.19 MP as WebP, with both outputs sitting on the same 40% quality floor — but the same ceiling applied to a 24-megapixel scan returned only 4.4% more pixels, and applied to a cut-out the gain was not pixels at all but the 71.91% of the image that JPG turned white. Same tool, same day, same ceiling: the coefficient you get is a property of the picture, not of the format, and the only way to know yours is to run the file once in each format and read the two output dimensions.