How the Client-Side Image Compressor works
How it works
The compressor reads the selected file through the File API and decodes it into an in-memory HTMLImageElement, then you choose an output format (lossy JPG, lossy WebP, or lossless PNG), a quality value from 0.1 to 1, and a target width. The height follows automatically to preserve the original aspect ratio, so one number controls both dimensions. The image is then drawn onto a 2D canvas with drawImage, which copies the decoded pixels into the drawing buffer. For JPEG output the tool paints a solid white background first, because the format has no alpha channel, while WebP and PNG keep transparency. Finally, canvas.toBlob calls the browser's encoder with the chosen MIME type and quality, and the resulting Blob is offered as a download.
The target width is capped at the source image's natural width, so the tool never upscales. Enlarging would only interpolate pixels without adding real detail. The quality slider drives the encoder for lossy formats, and for PNG it is ignored, because PNG compresses without discarding data. Every step runs inside the browser, so nothing is uploaded.
Compression works differently per format, and the difference is a trade between file size and fidelity. JPEG is lossy, because its encoder approximates blocks of pixels with a discrete cosine transform and drops high-frequency detail the eye can barely perceive. That is why photos in JPEG are far smaller than raw pixel data. PNG is lossless, using a reversible filtering step and deflate-style compression so every pixel survives exactly, at the cost of larger files. WebP sits in the middle and supports both modes in the same format, with an alpha channel like PNG. Once high-frequency content is discarded, no format reconstructs the original exactly, and that is the price you accept for a smaller file. The slider never restores detail that was already dropped.
Compression is a trade, not a magic setting. Size is bought with detail.
Use cases
People use this tool to shrink photos before emailing them, uploading them to a website, or posting them to social platforms, and to fit images under strict file-size limits without installing desktop software. Format choice follows content more than taste. Photos with smooth gradients suit lossy JPG or WebP. Screenshots, logos, and anything with sharp edges, small text, or flat color stay cleaner as PNG or lossless WebP. Anything needing transparency must be PNG or WebP, since JPEG has no alpha channel. Lossy encoders smear hard edges and muddy small glyphs, so the quality value matters less than the right format.
Troubleshooting
If a transparent PNG comes out with a white background, check the output format. JPG fills transparency with white, because it has no alpha channel. Switch to PNG or WebP. If the quality slider seems dead, you are likely encoding to PNG, a lossless format.
Very large images can be slow, and the largest can fail. Browsers cap canvas dimensions, and decoding a huge file consumes memory, so one browser can handle it while another cannot. Reduce the target width. If the page reports Canvas is unavailable, that environment has no 2D canvas support. The canvas works on single raster frames, so an animated input such as a GIF is compressed as one still image. All output formats are stills.
If the output looks rotated, the photo carries an EXIF orientation tag. Phone cameras store rotation there, and browsers apply the tag when decoding. Skipping it in a viewer renders the image sideways.
Browser behavior and differences
Canvas limits are engine specific. Browsers define their own maximum canvas dimensions and total pixel area, and those values differ between engines, which is why an extreme image can render in one browser and fail in the next. Image orientation is a platform behavior. The HTML standard describes how browsers handle EXIF rotation during decoding, so a photo can look upright in a browser and rotated in a tool that ignores the tag.
WebP is broad but not universal. Current browsers accept it across major platforms, while older environments may not, so check the caniuse coverage table before choosing WebP output.
When in doubt, test the exported file in the browser you deploy to.
Common mistakes
Picking JPG for an image that needs transparency, then wondering where the alpha went. Expecting the quality slider to shrink a PNG export. More retained detail means a larger file.
Trying to enlarge a small photo to make it sharper. Upscaling only interpolates pixels, so a small logo stays soft when stretched. The width cap exists for exactly this reason.
Reusing a phone photo before normalizing its EXIF tag can surprise viewers who consume the file elsewhere.
Alternatives
For heavier pipelines, dedicated tools offer more control. cwebp, ImageMagick, and Node libraries such as sharp can batch-process many files, and CDNs can re-encode images on the fly. Newer formats such as AVIF add different trade-offs where supported.
This tool covers what none of that does: no installation, no batch, no upload, nothing leaves your device.