{{ item.title }}{{ item.status }}
{{ item.detail }}
Image Compressor
Compress one image locally in your browser, compare size and visual quality, then download a resized or reformatted copy with metadata controls.{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ actualFormatLabel }} {{ outputDimensionsLabel }} {{ savingsLabel }}
Enabled is the neutral browser-photo default and does not change non-oriented sources.
{{ check_orientation ? 'Orientation correction on' : 'Use decoded pixel orientation' }}
| Measure | Value | Review note | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.note }} |
{{ tableExportAnnouncement }}
Optimization guidance
{{ chartExportAnnouncement }}
Image compression is a delivery decision, not just a hunt for the smallest file. A lighter image can load faster, fit an upload limit, and travel more easily by email, but aggressive encoding or resizing can soften text, blur fine texture, band gradients, or damage transparency.
Three choices do most of the work. Pixel dimensions determine how much visual information remains. The output format determines whether transparency and exact pixel values can survive. Encoding quality controls how aggressively JPEG or WebP discard detail. A useful comparison therefore checks the picture and its byte count together.
| Format | Best fit | Main tradeoff |
|---|---|---|
| JPEG | Photographs and broadly compatible delivery copies | Lossy and cannot preserve transparency; transparent pixels need a chosen background. |
| WebP | Compact modern web images | Lossy at the settings used here, with results that vary by image and browser encoder. |
| PNG | Transparency, diagrams, and exact flat-color pixels | Lossless output may be larger, and a quality target does not apply. |
Resizing often saves more bytes than a small quality adjustment because it removes pixels before encoding. That can be appropriate for a profile photo or web asset, but it is irreversible in the delivery copy. Keep the original, compare edges and gradients at useful viewing size, and confirm that the destination accepts the chosen dimensions and format.
Metadata deserves a separate check. Re-encoding can remove supported camera information by default, yet it may also drop color profiles or other fields a professional workflow needs. Animated input is another boundary: drawing an animated image into a still-image canvas uses a default or first frame, so this workflow is for still delivery copies rather than animation-preserving compression.
How to Use This Tool:
Start from the receiving system's real constraint, then change only the settings needed to meet it.
- Drop, paste, or browse one browser-readable image. Files must be no larger than 80 MB, 12,000 pixels on either side, or 64 megapixels.
- Choose a Compression preset or set the Output format, Encoding quality, and Resize mode yourself. For JPEG, select the background that should replace transparent pixels.
- Enter a positive Target size only for JPEG or WebP. Leave it at 0 when the quality slider should control encoding directly.
- Decide whether supported EXIF should remain. Orientation correction is on by default so camera-tagged photos are rotated before the delivery copy is written.
- Compare the source and optimized image, then check the compression ledger for actual format, dimensions, byte savings, target status, and metadata handling before downloading.
Interpreting Results:
A smaller byte count is useful only when the image still serves its destination. Inspect fine text, sharp edges, skin texture, gradients, transparent boundaries, and the JPEG matte. The split preview helps reveal visible change, while the ledger confirms the encoded file rather than an estimate.
- Strong means at least 40% fewer bytes; Moderate begins at 10%; Small covers savings below 10% down to no change.
- Larger means the output contains more bytes than the source. This can happen after format conversion or when a small source is re-encoded.
- Target met means the final JPEG or WebP is at or below the requested byte budget. A nearby result above the target remains Target missed.
- Quality numbers are encoder instructions, not universal visual scores. A quality of 75 in JPEG is not directly comparable with 75 in WebP or with another image.
Technical Details:
Compression combines geometric planning with browser image decoding and encoding. Geometry is calculated first, with both dimensions rounded to whole pixels and never allowed below one pixel. The decoded image is then re-encoded as JPEG, WebP, or PNG using the planned frame.
Formula Core:
Byte savings compares the encoded output with the original file. A negative result means the new file grew.
Bin and Bout are the original and encoded byte counts. Displayed kilobytes divide bytes by 1,024. Pixel change uses the same ratio pattern with source and planned pixel areas.
Transformation Core:
| Stage | Governing behavior |
|---|---|
| Decode | The browser must be able to read the source. An animated source becomes a still frame rather than a preserved animation. |
| Plan dimensions | Fit scales down to remain inside the width and height limits and never enlarges. Scale applies 1% to 200%. Long edge scales the longer side to the requested pixels and may enlarge. |
| Prepare pixels | Supported EXIF orientation can be applied. JPEG fills transparency with the selected matte before encoding. |
| Encode | JPEG and WebP use a quality ratio from 0.10 to 1.00. PNG is lossless in this workflow and ignores quality targets. |
| Measure | The final encoded file supplies the actual MIME type, byte count, and dimensions reported in the result. |
A positive target starts a bounded quality search for lossy output. It tests at most eight encodes between quality 0.25 and 1.00, retaining the closest result. Search may stop when the result is within the larger of 8,192 bytes or 4% of the target, but the final status says Target met only when the output is no larger than the target itself. Exact size is not guaranteed because encoders and image content respond nonlinearly to quality changes.
Bounds and Result Rules:
| Item | Exact rule |
|---|---|
| Source file | 1 byte to 80 MB (83,886,080 bytes) |
| Canvas | At most 12,000 pixels per side and 64,000,000 pixels total |
| Fit limits | At least one of maximum width or height must be positive |
| Target | 0 to 102,400 KB, with 1 KB treated as 1,024 bytes; active only when positive and output is JPEG or WebP |
| Savings bands | Strong ≥ 40%; Moderate ≥ 10% and < 40%; Small ≥ 0% and < 10%; Larger < 0% |
Privacy Notes:
The source pixels and generated image stay in browser memory for the current page. They are not uploaded, stored, or placed in the shareable page settings.
- Supported EXIF is stripped by default. Enabling Keep EXIF may retain camera, timestamp, device, or location-like fields.
- Re-encoding is not a complete metadata audit. Color profiles and format-specific information may be removed, changed, or remain outside the supported EXIF path.
- Keep the original until visual quality, orientation, color, transparency, dimensions, and required metadata have all been checked.
Worked Examples:
Photo for a 500 KiB upload limit
A 4,000 × 3,000 photo can be fitted inside 1,600 × 1,600 and encoded as WebP with a 500 KB target. The planned frame becomes 1,600 × 1,200. If the final file is 400,000 bytes, the ledger reports 390.625 KB, 90% byte savings, 84% fewer pixels, and Target met. The preview still decides whether that reduction is visually acceptable.
Transparent mark for a white page
Converting a transparent logo to JPEG requires a matte because JPEG cannot retain alpha transparency. Choose white only when the destination background is white; otherwise a visible halo can appear around antialiased edges. PNG avoids that matte but may produce a larger delivery file.
References:
- HTML Standard: Canvas, WHATWG, Living Standard.
- How to compress an image with ImageMagick, Simplified Guide.
- How to strip image metadata with ImageMagick, Simplified Guide.