Skip to main content
Image Transformer

Image Compressor and Dimension Resizer

Process up to 20 PNG, JPEG, or WebP images locally with Canvas, optional 400-3000 px bounds, and browser JPEG/WebP quality from 10% to 100%. Ideal for web developers, content creators, and anyone reducing file sizes before upload without losing control over quality settings. All processing stays in the browser.

Image tools

Drag image files herePNG, JPEG, WebP up to 50 MB each

Upload or select an image to compare before and after compression.

75%
1200px
1200px
Compression runs fully inside browser memory with native Canvas encoders. No uploads are performed.

In brief

Resize and re-encode selected images without upload, while accounting for decoded-memory cost, metadata loss, transparency, browser-dependent encoders, and PNG’s lack of a variable quality setting.

What this tool supports

  • PNG, JPEG/JPG, or WebP files selected or dropped; at most 20 files, 50 MB per file, and 10,000 pixels on either decoded source dimension.
  • Files are read as data URLs, decoded into Image elements, proportionally fitted within optional maximum width/height, drawn to Canvas, and encoded sequentially with toBlob.
  • Each result can keep the original MIME type or request JPEG/WebP, then downloads with _compressed and the chosen extension; displayed sizes and savings come from actual result blobs.
  • Resize/compress first, then create a data URL with Base64 File Converter only when an embedding format truly requires it.
  • No. Canvas redraw normally discards metadata and animation frames, may change color handling, and re-encoding can produce a larger file.

How to use Image Compressor and Dimension Resizer

Complete a verifiable Image Compressor and Dimension Resizer workflow in this browser.

  1. 1

    Step 1

    Provide the exact input

    PNG, JPEG/JPG, or WebP files selected or dropped; at most 20 files, 50 MB per file, and 10,000 pixels on either decoded source dimension.

  2. 2

    Step 2

    Set the available controls

    Set 10–100% quality, optional 400–3000 px maximum width/height, output Original/JPEG/WebP, and metadata-removal intent.

  3. 3

    Step 3

    Run the operation

    Files are read as data URLs, decoded into Image elements, proportionally fitted within optional maximum width/height, drawn to Canvas, and encoded sequentially with toBlob.

  4. 4

    Step 4

    Verify the result

    For a 2400×1600 image with both maxima at 1200, verify 1200×800 dimensions; inspect the downloaded MIME type, transparency, orientation, and visual artifacts.

  5. 5

    Step 5

    Continue or export

    Resize/compress first, then create a data URL with Base64 File Converter only when an embedding format truly requires it.

Common mistakes

Estimating browser memory from the compressed file size alone

Consequence: A file can coexist as source bytes, a Base64 data URL, decoded RGBA pixels, a canvas, and an output blob. A permitted 50 MB file or large batch can therefore consume several times its disk size and stall or terminate the tab.

Fix: Check decoded dimensions and batch count, process the smallest practical batch, and close other memory-heavy tabs before handling large images.

Converting a transparent image to JPEG without checking the flattened pixels

Consequence: JPEG cannot represent alpha. Transparent and partially transparent pixels must be flattened by the encoder, so logos, shadows, or cutouts can gain an unintended background or edge artifacts.

Fix: Keep PNG or a verified WebP result when transparency matters, or flatten onto an intentional background before JPEG encoding and inspect the downloaded pixels.

Overlooking this edge case: Why can PNG ignore quality or an output differ between browsers?

Consequence: Canvas quality is only a hint for lossy encoders; PNG has no equivalent variable quality control, encoder implementations differ, and an unsupported requested MIME type may fall back to PNG.

Fix: Check the Blob MIME type and decoded pixels in every target browser, and use JPEG/WebP only when their loss and alpha behavior are acceptable.

Best practices

  • For a 2400×1600 image with both maxima at 1200, verify 1200×800 dimensions; inspect the downloaded MIME type, transparency, orientation, and visual artifacts.
  • Check the Blob MIME type and decoded pixels in every target browser, and use JPEG/WebP only when their loss and alpha behavior are acceptable.
  • Keep originals and compare visual quality at 100% zoom before deleting source assets.

Connected workflows

Resize, encode, and inspect a publishable image

Image Compressor and Dimension ResizerImage ResizerFile to Base64 Data URL Converter

Resize/compress first, then create a data URL with Base64 File Converter only when an embedding format truly requires it.

  1. Keep the original files and record their decoded dimensions, orientation, and transparency
  2. Choose proportional width and height bounds plus an output format suited to alpha and quality needs
  3. Compress a small batch locally and wait for every result blob
  4. Inspect actual dimensions, MIME type, alpha, orientation, byte size, and artifacts at 100% zoom
  5. Publish the reviewed file or create a data URL only when the receiving format requires embedding

Browser limitations

  • Canvas quality is only a hint for lossy encoders; PNG has no equivalent variable quality control, encoder implementations differ, and an unsupported requested MIME type may fall back to PNG.
  • A compressed file can occupy several simultaneous representations—source bytes, Base64 data URL, decoded pixels, canvas, and output blob—so 50 MB input is not a safe memory estimate.
  • Canvas encoder availability and quality differ by engine; Clipboard/Downloads need user gestures, and unsupported or corrupted images can fail during decode.

Authoritative resources

HTML Standard: Serializing bitmaps to a filePublisher: WHATWG · Reviewed: 2026-07-26File APIPublisher: W3C · Reviewed: 2026-07-26PNG Specification, Third EditionPublisher: W3C · Reviewed: 2026-07-26

Concrete examples

Input
photo.jpg: 2400×1600; max width 1200; max height 1200; JPEG output
Result
photo_compressed.jpg: 1200×800

The aspect ratio is 3:2, so fitting inside 1200×1200 yields deterministic dimensions; compressed byte size remains encoder- and content-dependent.

Frequently asked questions

Which formats, file counts, byte sizes, and decoded dimensions are accepted?

PNG, JPEG/JPG, or WebP files selected or dropped; at most 20 files, 50 MB per file, and 10,000 pixels on either decoded source dimension.

Why can PNG ignore quality or an output differ between browsers?

Canvas quality is only a hint for lossy encoders; PNG has no equivalent variable quality control, encoder implementations differ, and an unsupported requested MIME type may fall back to PNG.

Does the tool preserve animation, EXIF, color profiles, or guarantee a smaller file?

No. Canvas redraw normally discards metadata and animation frames, may change color handling, and re-encoding can produce a larger file.

What should I inspect besides the reported byte saving?

For a 2400×1600 image with both maxima at 1200, verify 1200×800 dimensions; inspect the downloaded MIME type, transparency, orientation, and visual artifacts.

Are source files, decoded pixels, or result blobs uploaded?

File bytes, decoded pixels, canvases, and result blobs stay on this device; no image is uploaded. Downloads and offline use remain browser-controlled.

When is a Base64 data URL an appropriate next step?

Resize/compress first, then create a data URL with Base64 File Converter only when an embedding format truly requires it.

Privacy and offline behavior

File bytes, decoded pixels, canvases, and result blobs stay on this device; no image is uploaded. Downloads and offline use remain browser-controlled.