01What changes when you compress an image
Lossy encoding discards some image information so the remaining data can be stored more compactly. Lossless encoding preserves the decoded pixels, but it cannot promise a smaller file—especially when the source is already optimized. Quality numbers are encoder settings, not universal visual-quality scores, and the same number is not equivalent across JPG, WebP, AVIF or different implementations.
PNG output in this tool uses palette quantization with 16 to 256 colors. That can work well for some graphics, but it can also change gradients, text edges, colors and soft transparency. Auto compares the formats available in your browser, checks every output pixel for transparency before admitting JPG, and keeps the original bytes when every tested re-encode is larger.
The batch gauge measures byte reduction only. It does not certify sharpness, color accuracy or visual quality.
- Quality mode applies the selected setting when no byte target is active.
- Target mode searches quality settings and labels a target miss instead of hiding it.
- Auto compares actual output sizes; it does not assume one format always wins.
- A no-gain result downloads the original bytes rather than a larger “compressed” file.
02Choose JPG, PNG, WebP or AVIF for the actual image
JPG is widely supported but cannot hold transparency. PNG can preserve exact pixels in its full form, while this tool’s PNG8 output deliberately reduces the palette. WebP and AVIF can encode photographs and transparency, but available encoders and decoding support depend on the browser. The tool verifies the returned MIME type, so an unsupported request cannot silently become PNG bytes with a WebP or AVIF extension.
There is no honest universal percentage by which WebP beats JPG or AVIF beats WebP. Image content, dimensions, encoder settings and implementation all matter. Compare the preview at the size where people will see it, then keep the smallest result that remains acceptable for that use.
- Photos for broad compatibility: test JPG, WebP and AVIF where supported.
- Graphics with transparency: test WebP, AVIF or PNG and inspect edges closely.
- Archival or pixel-exact work: retain the master; this compressor is not a lossless archival workflow.
- Still GIF input can be converted; animated GIF, WebP, APNG and AVIF sequences are rejected without flattening frames.
03Compress to 50 KB, 100 KB or another decimal target
Open “Target size & resize” to choose a preset or enter a custom ceiling. This tool uses decimal units: 1 KB equals 1,000 bytes, so a 100 KB target means 100,000 bytes. That convention matches many upload forms, but a particular form may use a different rule or count an entire multipart request rather than only the file.
For a selected output format, the encoder first tests the floor and then searches quality settings for a result at or below the ceiling. With Auto, the smallest tested result that fits is selected. If quality alone cannot fit, optional dimension fallback tries smaller dimensions. If the ceiling remains unreachable, the result says so; it never swaps the byte unit or pretends an oversized file met the target.
A byte target is a size constraint, not a visual-quality guarantee. Inspect the result before replacing the source.
04Resize for the display, not just the codec
Dimensions and compression solve different problems. Re-encoding changes how pixels are stored; resizing changes how many pixels exist. If an image will only appear in a small container, delivering a much larger raster can waste transfer and decoding work. Choose a maximum width, height or longest side, or use a percentage preset. The tool only shrinks and never enlarges an image.
For a responsive site, generate the sizes your layout actually needs and use width and height attributes plus an appropriate srcset and sizes declaration. A single “best width” cannot fit every layout, device pixel ratio or art-direction choice. Also remember that reducing dimensions can remove detail needed for zoom, cropping or print.
05Metadata, orientation and local processing
A newly encoded canvas file does not carry forward EXIF or other embedded source metadata. That can remove camera details and location fields, but it also removes metadata you may need for rights, provenance or archival work. When the compressor keeps the original because re-encoding offers no gain, it keeps the original bytes and their metadata too; the interface states which case occurred.
Image files are decoded and encoded in the browser rather than uploaded to Swiftly. The page, scripts and dynamically loaded codecs still need to be available, so “local processing” is not a promise that a first visit works offline. After the necessary assets have loaded, some operations may continue without a network; codec availability still varies by browser.
06Limits, animation and final quality checks
The batch accepts up to 50 still images, 50 MB per file and 100 megapixels per decoded image. These are product safety limits, not guarantees that every device has enough memory. Very large images can hit a lower browser canvas or memory ceiling; in that case the tool reports an error instead of leaving a permanent loading skeleton.
Animated formats are rejected during signature inspection so the tool cannot silently return only their first frame. HEIC and HEIF are not accepted. Before publishing a compressed result, inspect fine text, faces, gradients, transparent edges and saturated colors at the intended display size. Keep the original master and repeat the check after any further resize, format conversion or content-management-system optimization.