Image Formats and Compression Explained: JPEG, PNG, WEBP and GIF in the Photo Compressor Chrome Extension
This is the technical reference for the photo compressor Chrome extension that compresses images — photos and pictures alike — right inside the browser. It covers what actually happens to each format, why files typically shrink by 50–70%, how target-size compression works, and where the limits are. Install it directly from the Install from the Chrome Web Store listing to try any of this yourself.
The short version: every format on this page behaves differently because it was designed for a different kind of picture. JPEG throws away detail a viewer barely notices; PNG and GIF repack the same pixels without losing any of them; WEBP does both. Understanding which is which explains why a screenshot and a photograph compress so differently, and what the extension’s target-size search can and cannot do. For the feature list behind these numbers, see /features/; for short answers to the most common questions, see the FAQ.
Lossy and lossless: the one distinction that explains everything
Nearly every question about image compression traces back to a single fork: does the algorithm discard pixel data permanently, or does it only repack the same data more efficiently? MDN’s image file type guide frames the same split, and it is the fork the picture compressor extension’s format list is built around — JPEG on one side, PNG and GIF on the other, WEBP straddling both.
What lossy compression actually throws away
JPEG cuts a picture into 8×8 pixel blocks, converts each block into frequencies with a discrete cosine transform (DCT), and then quantizes the high frequencies more coarsely than the low ones — that is, it rounds off fine texture and subtle color transitions more aggressively than broad shapes. The quality slider controls how coarse that rounding gets. Because the discarded detail is gone for good, re-saving an already-compressed JPEG stacks new losses on top of the old ones, a compounding effect known as generation loss. On a typical photograph, JPEG at quality 85 comes out around 142 KB versus roughly 253 KB at quality 95 — a 44% difference for a change most viewers won’t spot side by side.
What lossless compression does instead
PNG uses DEFLATE, the same general-purpose algorithm behind ZIP archives: it looks for repeated byte patterns and replaces them with shorter references, without discarding a single pixel. GIF instead runs LZW over an 8-bit indexed palette, capping the image at 256 distinct colors. That difference in method explains the gap in results — the same photograph that comes out around 142 KB as a JPEG can balloon to roughly 955 KB as a PNG, nearly seven times larger, because lossless formats have nothing to throw away on a file full of gradual color shifts. Flat graphics behave the opposite way.
Compressing is not resizing
It helps to separate two operations people often lump together. Compressing changes how the same pixels are stored on disk — fewer bytes, same picture dimensions. Resizing removes pixels outright, producing a physically smaller image. The Photo Compressor extension compresses; it does not change resolution, so a 4000×3000 photo stays 4000×3000 pixels after processing, just represented in fewer bytes.
The four formats the extension handles
The extension reads and writes four formats end to end: JPEG, PNG, WEBP and GIF. Each has its own ceiling, its own transparency support, and its own typical use case, summarized below.
| Format | Compression type | Max transparency | Practical ceiling |
|---|---|---|---|
| JPEG/JPG | Lossy (DCT-based) | None | Up to 65,535 × 65,535 px |
| PNG | Lossless (DEFLATE) | Full 8-bit or 16-bit alpha | No hard pixel-dimension cap |
| WEBP | Lossy or lossless | Full alpha, plus animation | Up to 16,383 × 16,383 px |
| GIF | Lossless (LZW, indexed) | 1-bit (on/off) only | 256 colors per frame |
JPEG and JPG: photographs
JPEG and JPG are the same format under two different file extensions — nothing distinguishes them beyond the three-versus-four letter suffix. It is lossy by definition and carries no alpha channel at all. This is also where the extension’s compression delivers the most: photographs are exactly the content type JPEG’s DCT-based approach was built to shrink, which is why the typical 50–70% reduction shows up most reliably here.
PNG: screenshots, logos, transparency
A screenshot and a photograph compress very differently under PNG, and the reason is the algorithm, not the content. Flat color fields and crisp text — the kind of thing a UI screenshot is made of — repeat constantly at the byte level, so DEFLATE finds long matches and the file shrinks hard. A photograph rarely repeats anything exactly, so PNG’s lossless approach barely helps and can even inflate the file. Because the extension keeps PNG output as PNG rather than silently converting it to JPEG, the alpha channel survives the process intact — no white background fill, no lost transparency.
WEBP: both modes in one format
WEBP is the one format on this list that supports both lossy and lossless encoding in a single container, plus alpha transparency and animation. Google’s own comparative study found WEBP lossy files run 25–34% smaller than JPEG at equivalent SSIM (a structural-similarity quality metric), and WEBP lossless comes in around 26% smaller than PNG at the same fidelity. Browser support sits at roughly 97–98% as of 2026, which is high enough for almost any web use — the remaining edge cases tend to be email clients and print workflows that still expect JPEG or PNG specifically.
GIF: palette and animation
GIF is supported, and it is worth being direct about what that means. GIF stores an image against an indexed palette capped at 256 colors, which is fine for simple graphics and icons but a hard limit for anything photographic. Animated GIFs are a special case: a multi-frame file is a sequence of palette-indexed frames, not a single image, so it does not compress the same way a static picture does, and results on animated files are not guaranteed to match the numbers this page quotes for single images.
Transparency, animation and EXIF: what survives
Because the extension outputs the same format it received, format-level behavior around transparency and metadata carries straight through the compression step.
Transparency
PNG and WEBP both carry full alpha transparency, and since a PNG stays a PNG and a WEBP stays a WEBP through compression, whatever transparency existed going in is still there coming out. JPEG is the exception worth flagging clearly: it has no alpha channel at all, by specification, so there is nothing to preserve or lose — a JPEG was never transparent to begin with.
EXIF and other metadata
EXIF metadata — the capture date, camera model, lens settings, and sometimes GPS coordinates embedded by a camera or phone — follows the CIPA DC-008 Exif standard. When the extension re-encodes a file through the browser’s Canvas API, that re-encoding does not carry EXIF fields through: the compressed output is built from pixel data, not from the original file’s metadata block. If EXIF preservation matters for a specific file, that is worth checking before relying on the compressed copy.
Where 50-70% comes from
The 50–70% figure is not a marketing round number; it is the typical range seen across real batches run through the side panel, though results vary by file.
The numbers on real files
Across real files run through the extension, reductions of -64%, -72%, -61%, -66%, -61% and -53% are typical, with individual before/after pairs like 157.6 KB → 56.0 KB and 348 KB → 150.3 KB. On some individual files the reduction reaches as high as 90%, but 50–70% is the honest range to expect on a normal mixed batch — not “up to 92%” quoted as if it were routine.
What the result depends on
- Prior compression. A JPEG that has already been compressed once has little redundant data left to remove, so a second pass yields far less.
- Content type. A PNG screenshot with flat color and text compresses aggressively; a noisy, detail-heavy photograph compresses less than a smooth one at the same resolution.
- Starting file size. A small file already close to its practical floor shows a smaller percentage improvement than a large, uncompressed original.
- Format choice. Switching a photographic PNG to JPEG or WEBP on output tends to save far more than staying in PNG, because the algorithm finally matches the content.
Compressing to a target size in kilobytes
This is where the extension does something none of the compared alternatives offer: instead of only a quality slider, it lets a user specify a target size in kilobytes and works toward it directly.
Why the tool searches instead of calculating
The output size of a compressed file cannot be calculated in advance — it depends entirely on the image’s content, not just its dimensions. So reaching a target size means encoding the file, checking the resulting weight, adjusting the quality setting, and repeating until the result lands at or under the target. Note also that in the browser’s HTMLCanvasElement.toBlob() API, the quality parameter only affects image/jpeg and image/webp output — it has no effect on image/png, which is one reason target-size compression is most precise on JPEG and WEBP.
- Set the desired output size in kilobytes.
- The tool encodes the image at an initial quality level.
- It checks the resulting file size against the target.
- If the file is too large, it lowers quality and re-encodes.
- If the file undershoots by a wide margin, it can raise quality and re-encode.
- The search repeats until the result is at or under the target size.
- The closest achievable file within that ceiling is delivered.
When the target is unreachable
There is a floor. A large image still carries the weight of its own pixel grid even at very low quality, so an aggressive target — say, forcing a 6000-pixel-wide photo down to 20 KB — can hit a wall the quality slider alone cannot cross. At that point, reducing the pixel dimensions, not just the quality, is the only way to reach the number. This is the honest answer to whether a JPEG can be compressed to exactly 100 KB: the tool converges to a value at or under the target, not to an exact byte count, and if that target sits below what the resolution allows, resizing is required first.
Permissions and where the processing happens
The extension’s Chrome Web Store listing states plainly: “The developer has disclosed that it will not collect or use your data.” The permissions below are what make the /workspace/ side panel and right-click compression work.
| Permission | Chrome’s official description | What it is used for |
|---|---|---|
activeTab | Temporary access to the currently active tab, granted through a user gesture | Reading an image the user clicks or right-clicks on the page they’re viewing |
storage | Access to the chrome.storage API | Remembering settings like theme and default quality between sessions |
sidePanel | Access to the chrome.sidePanel API | Powering the persistent side panel interface, as opposed to a popup that closes on an outside click |
contextMenus | Access to the chrome.contextMenus API | Adding the “Compress Image” right-click option on images across the web |
Local processing
All compression runs inside the browser tab itself. Files are not uploaded to a remote server, and no image data is collected in the process — the extension’s own store listing states this directly rather than as a headline claim.
According to Chrome’s own sidePanel API documentation, the side panel is designed to stay open as a user navigates between tabs, rather than closing the moment focus moves elsewhere the way a browser action popup does — which is exactly the persistent behavior the extension’s side panel relies on.
Limits and known behaviour
File size and batch size
There is no hard-coded file count or file size quota built into the extension. The real ceiling is the memory available to the browser tab: very large source files or very long batches can run into that limit before they run into anything the extension itself imposes.
What is not supported
SVG, HEIC and camera RAW files fall outside the four formats the extension reads and writes. SVG is a vector format, not a pixel grid, so it doesn’t fit the same compression model at all. HEIC and RAW files are not formats Chrome decodes natively, which keeps them out of scope for a browser-based tool like this one.
Official specifications and documentation
- MDN — Image file type and format guide
- MDN — HTMLCanvasElement.toBlob()
- Google — A comparative study of WebP, JPEG and PNG
- W3C — PNG (Portable Network Graphics) specification
- W3.org — GIF89a specification
- JPEG.org — the JPEG standard
- Chrome for Developers — extension permissions list
- Chrome for Developers — chrome.sidePanel API
- CIPA — Exif standard documentation
Frequently asked questions
For the full walkthrough of adding, compressing and downloading images, see /how-to-use/, or start from this image compressor documentation‘s home page and try it on a real file — Install from the Chrome Web Store.