Methodology

This page explains how our tools work under the hood, so you can understand the trade-offs and judge the results for yourself. Where something is a limitation, it is written here as a limitation rather than left for you to discover.

Browser-based processing

Every image is decoded with createImageBitmap(), drawn to a canvas (an OffscreenCanvas inside a Web Worker where supported), and re-encoded with canvas.toBlob(). The worker keeps the main thread free so the page stays responsive while a large photo encodes, and it means files never leave your device — there is no upload endpoint to send them to.

Where OffscreenCanvas or workers are unavailable, and always for SVG (which needs the DOM to parse safely), the same pipeline runs on the main thread instead. The output is the same; only the responsiveness of the page differs.

Format support

Writing to JPG flattens transparency onto the background color you pick in the settings panel — white unless you change it, never a silent black fill. Animated GIF and animated WebP are processed as their first frame, and the page says so rather than quietly discarding the rest.

JPEG compression

JPEG uses the browser's native lossy encoder. The quality value (0–100) controls how much high-frequency detail is discarded. We compress from the source you provide; we cannot recover detail that a previous JPEG save already removed, so working from the best original you have always gives a better result than re-compressing an export.

PNG optimization

PNG output is lossless, which is why the quality slider is disabled when PNG is selected rather than left live and ignored. To shrink a PNG we either re-encode it losslessly, reduce the color palette with a median-cut quantizer (which can band gradients and soft edges), or convert to WebP. Transparency is preserved throughout.

WebP & AVIF

WebP supports lossy and lossless modes with an alpha channel. AVIF usually compresses better still, but encoding is slow and support for creating it is much narrower than support for displaying it. We probe the browser at runtime and only offer AVIF output when that probe succeeds, so the option is never shown and then found to fail.

EXIF orientation

Decoding requests imageOrientation: 'from-image', so a photo tagged as rotated is turned upright in the pixels themselves before anything else happens. That is why an image whose metadata is then stripped does not end up sideways: the rotation has already been baked in.

Color profiles (ICC)

This is a real limitation and worth knowing before you process professional work. The canvas pipeline operates in the browser's canvas color space, and the encoded output does not carry across an ICC profile embedded in your source file. For the overwhelming majority of images — which are already sRGB — nothing visibly changes. For a wide-gamut original (Display P3, Adobe RGB, ProPhoto), saturated colors can shift, and the result is best treated as an sRGB copy. If color management matters to your workflow, keep the original and use a desktop application that manages profiles explicitly.

SVG handling

SVG is code, not just pixels, so it is parsed and sanitized before it is drawn: script, foreignObject, iframe, embed, object, audio, video and animation elements are removed; every on… event attribute is stripped; href is restricted to same-document references and inline data:image/ values; embedded stylesheets that use @import or fetch a remote URL are dropped; and any attribute containing a url() pointing outside the document is removed. Rasterizing happens through an <img> element loading a blob URL, which by specification does not run scripts or fetch subresources — the sanitizer is a second layer, not the only one.

Resizing

Resizing uses high-quality canvas resampling. Fit keeps the whole image inside a box, Fill covers the box with a center crop, and exact and percentage modes are also available. Upscaling is off by default because interpolation cannot add detail that was never captured — an enlarged image is a softer image, and the tool says so instead of implying otherwise.

Metadata removal

Because the output is rebuilt from raw pixels, EXIF, GPS, camera and timestamp fields are not carried into it. Some container-specific data can remain in certain formats, which we disclose rather than overstate. The metadata inspector lists the names of the groups it finds — never the values, so your GPS coordinates are not printed on screen on the way to being removed.

Target file size

Target-size mode runs a binary search on encoder quality between 0.3 and your chosen quality, up to eight steps, stopping when the search interval narrows below 0.02. If the smallest quality in that range still exceeds your target, it then steps the resolution down by 15% at a time, up to six times, with a floor of 64 px on either side, re-encoding at each step.

There is no exact-size guarantee — encoders do not work that way. The result is reported as reached when it is at or under the target, close when it is within 15% above it, and missed otherwise, and when the resolution had to be reduced to get there the tool tells you that too.

When the result is larger than the original

This happens, and it is not a bug. Re-encoding an already well-compressed file usually adds bytes rather than removing them; so does converting a photograph to PNG, or a small image to a format with a larger header. Every tool compares the two sizes and, when the output is bigger, labels it as an increase in a warning color, keeps your original selected, and suggests a different output format. It is never presented as a successful optimization.

Batch processing and limits

Multiple files run through a bounded queue with limited concurrency, so several high-resolution images do not all decode into memory at once. Object URLs, bitmaps and canvases are released as work completes, and cancelling terminates the worker outright rather than waiting for the file currently being encoded to finish.

• 25 MB per file.
• 20 files per batch.
• 40 megapixels per image, as a guard against decompression bombs.

These exist to protect your own browser, not a server — there is no server in the processing path. A tab that runs out of memory loses the whole queue, which is a far worse outcome than being asked to split a job in two.

How we source the numbers in our guides

We do not publish compression percentages of our own, because we have not run a documented, repeatable test suite that would justify them. Every figure in our guides is one of three things:

• Arithmetic you can check. Halving an image's width and height leaves a quarter of the pixels — that is a fact about pixels, not a measurement of an encoder.
• A figure attributed to whoever measured it, linked from a Sources section at the foot of the guide that quotes it, with the conditions of the measurement noted.
• An explicitly labelled illustration, marked as such in the text so it is never mistaken for a result.

Ranges quoted from a published study are averages across a corpus. Your image is not a corpus: the tools show you the real before and after sizes for your own file, and that number is the one to trust.

Editorial policy and corrections

Guides are written and reviewed by the LITTLEImg editorial team. We do not invent expert bylines, testimonials, ratings or awards, and there are none anywhere on this site. If you find a claim on any page that is wrong, out of date, or that the tools do not actually do, please tell us — corrections to factual errors are made directly on the page, and the guide's updated date changes with them.

Known limitations & browser differences

• Animated GIF and animated WebP are processed as a single frame.
• HEIC decoding is disabled by default because of inconsistent browser support.
• Encoder output differs slightly across browsers and operating systems, so the same settings can produce a slightly different file size on a different machine.
• AVIF encoding is unavailable in browsers that cannot produce it; the option is hidden rather than offered.
• ICC color profiles are not carried into the output, as described above.
• SVG is rasterized at its intrinsic size, or 1024 px when it declares none.