The Image Studio's Quality Slider: Twelve Measured Sizes and the PNG That Got Bigger

I work on OnePassApps, the team behind app.onepassapps.com, so this is our own build measured in our own tab.

Our earlier post on this tab looked at one thing: where transparent pixels go when you save a PNG as JPEG. It left the quality slider alone on purpose and said so - the default was 86, and guessing what the other settings do to the byte counts would have been guesswork.

This post measures the slider instead. Twelve conversions, one source image, and the byte counts read back off the files that landed on disk.

You can try it on the Image Studio, or see how it sits with the rest of the suite in the app guides.

What the tab is

The page line is plain: "Convert, compress, resize, crop and clean images in your browser. Nothing leaves this tab." The stage under the file repeats it: "Processing stays in this browser."

Convert is the first of seven tabs: Convert, Compress, Resize, Crop, Remove background, Remove metadata, Images to PDF.

The output step offers three formats - PNG, JPEG and WebP - and one line of advice that changes with the format you pick:

• PNG: "PNG is lossless and keeps transparency."
• JPEG: "JPEG has no transparency, so transparent areas become white."
• WebP: "WebP keeps transparency and is usually the smallest."

The quality slider is there for JPEG and WebP. Pick PNG and the slider is not rendered at all - the panel shows Format, PNG, JPEG, WebP and then goes straight to the advice line. Where the slider is present it runs from 10 to 100 in steps of 1 and starts at 86.

The source

A 1200 × 630 PNG we drew ourselves for a card on an earlier post. On disk it is 67,120 bytes, and the panel calls it "PNG · 1200 × 630 · 65.5 KiB".

Dimensions never move on this tab. Every single result read back "Dimensions 1200 × 630".

PNG to PNG: the same pixels, more bytes

Converting the PNG to PNG is the odd one out. The result card read "PNG · 1200 × 630 · 95.4 KiB · 45% larger", and the downloaded file was 97,643 bytes against 67,120 on disk - 45.5% more bytes for an image whose pixels did not move.

I checked that twice. Inside the page, the source and the result were both drawn to a canvas and compared channel by channel: 756,000 pixels, 3,024,000 channel values, 0 differing channels, maximum channel delta 0. Then off disk, the downloaded PNG was opened with an image library and compared to the original the same way - identical, pixel for pixel.

So the panel's "PNG is lossless" is exactly true, and the "45% larger" is exactly true at the same time. Lossless means the pixels are unchanged. It does not mean the file is small, and re-encoding an already-optimised PNG in a browser canvas is a good way to make it heavier.

JPEG at the default is bigger than the PNG

Left at the default 86, the JPEG result card read "JPEG · 1200 × 630 · 81.6 KiB · 24% larger". The downloaded file was 83,515 bytes with the header ff d8 ff e0, a plain JFIF JPEG.

Comparing the rendered JPEG against the rendered source: 1,075,139 of 3,024,000 channel values differ, and the largest single-channel gap is 75. That is what lossy means in practice, and it is why a JPEG of a flat graphic is often heavier than the PNG it came from.

The slider, twelve points

Same source file, slider stepped through six settings for each lossy format. Each row is the size the result panel printed, with the panel's own percentage in brackets. The panel prints the pair in one line - at quality 10 it reads "JPEG · 1200 × 630 · 20.1 KiB · 69% smaller". The panel prints the pair in one line - at quality 10 it reads "JPEG · 1200 × 630 · 20.1 KiB · 69% smaller". The panel prints the pair in one line - at quality 10 it reads "JPEG · 1200 × 630 · 20.1 KiB · 69% smaller".

Three things fall out of that table.

Quality 75 is the first JPEG that is actually smaller than the PNG. At 62.3 KiB it comes in 4.9% smaller; at the default 86 it is 24% larger; at 100 it is 276.2 KiB, or "321% larger", the biggest file in the whole run.

WebP is smaller than JPEG at every point I measured - 18.3 against 20.1 at the bottom, 49.3 against 81.6 at the default, 91.5 against 276.2 at the top. The gap widens as the setting rises, because at 100 the JPEG carries far more data than the WebP does.

The size curve is steep at the top. Going from 75 to 100 takes the JPEG from 62.3 KiB to 276.2 KiB, more than four times the size, for a setting most people never move.

Transparency, checked at the pixels

To test the panel's own warnings I made a second fixture: a 64 × 64 RGBA PNG - the panel reads it as 158 B - left half opaque red, right half fully transparent. Then I read the corner pixel of each rendered result.

• PNG: the transparent corner reads 0, 0, 0, 0. The alpha channel survives.
• WebP: the same corner reads 0, 0, 0, 0. Alpha survives too.
• JPEG: the same corner reads 255, 255, 255, 255 - white, fully opaque.

That is the panel's "JPEG has no transparency, so transparent areas become white" confirmed at the pixel, and "WebP keeps transparency" confirmed the same way. The PNG result for that fixture was 293 bytes, the WebP 614, the JPEG 811 - on a file this small every format is bigger than the input, which is expected and is not a size claim about real photographs.

The file name rule

The output keeps the base name and swaps the extension: citation-export-card-2026-11-08.png became citation-export-card-2026-11-08.jpg for JPEG and citation-export-card-2026-11-08.webp for WebP. Nothing is renamed, and the panel ends every run with "Finished. Download a new copy; the original stays unchanged."

The wire

In a session with the network log on, the tab made 110 requests. Every one was a GET, none carried a request body, and the only hosts reached were clerk.onepassapps.com, api.onepassapps.com and app.onepassapps.com. The file's name appeared in no request URL - the converted images came back as blob: URLs on app.onepassapps.com, which is where the bytes landed on disk.

What I did not measure

One build, one browser, one signed-out session, 8 November 2026. One source image for the ladder - a graphic with flat colour, so the JPEG percentages are that file's and are not a rule about photographs; a photographic PNG would behave differently at the same settings. The slider was set programmatically and its value was read back after every step, but I did not drag it with a mouse. The pixel comparisons were made by drawing the images to a canvas in the page and reading them back with getImageData, and off disk with an image library; I did not open the files in a photo editor. I measured the Convert tab only - not Compress, Resize, Crop, Remove background, Remove metadata or Images to PDF - and I made no claim about what another browser's canvas encoder would produce.

For the transparency side of this tab, see what happens to transparent pixels when you save a PNG as JPEG.

I work on OnePassApps, and every number above was measured on our own build in our own tab.