How to Resize and Compress Screenshots on Mac

The right screenshot format depends on what is inside the screenshot.

For a synthetic dashboard full of small labels, JPEG at a high quality setting was not automatically smaller than PNG. For a color and texture-heavy report, the same JPEG export was dramatically smaller. A lossless WebP preserved the resized pixels exactly, but one of its smaller-width outputs was larger than the same fixture at full width.

That is why I would stop asking for one universal “best format.” Resize to the width you actually need, then compare formats against the kind of image you are exporting.

The original question for this page was: How should I resize or compress a Mac screenshot without making it unreadable? I ran a small controlled study to answer the file-size part and to keep the readability claim honest.

The short answer

• Keep the original capture.
• Crop to the detail the reader needs, then resize a copy if necessary.
• Account for display density: an image shown at 800 CSS pixels can use 1600 image pixels on a 2× display.
• Use optimized PNG or lossless WebP when exact pixels matter.
• Try JPEG or lossy WebP for visual texture, and compare the actual exported size and detail.
• Check small text at the actual width before sending it.

“Lossless” means the export matches the resized reference pixels. It does not mean a 1600px image still contains the original 3200px capture. Resizing changes pixels before the encoder gets involved.

What I tested

I built three owned synthetic browser fixtures:

1. UI: a light dashboard with a table, status badges, borders and small labels.
2. Code: a dark editor with syntax colors, punctuation, monospace text and small text.
3. Visual: a color gradient with seeded texture and a white text overlay. It is a visual test pattern, not a photograph.

Each fixture was captured twice in fresh Chrome contexts at a 1600 × 900 CSS viewport with device scale factor 2. The resulting PNGs were 3200 × 1800 pixels. The two captures for each fixture were byte-identical.

These crops retain the original pixels. Open the image at full size for a 1:1 view; the page may scale it to fit.

From each original, I made five exports at three widths: 3200px, 1600px and 800px.

That produced 90 valid outputs. An earlier v1 run was excluded because a missing opening table-cell tag changed the fixture’s layout. The corrected run used Pillow 12.3.0, libwebp 1.6.0, LANCZOS resampling and opaque RGB images. This was a byte-size and pixel-integrity study, not an encoding-speed benchmark.

The public evidence archive contains the three original captures, 45 unique run-one exports, both run receipts, the 90-row measurement table and the reproduction scripts. Run-two images are omitted from the download because every repeat pair was byte-identical; the manifest records that decision.

The measured file sizes

These are bytes from run 1. Run 2 produced the same bytes for every matching fixture, width and export.

The first pattern is obvious: the visual fixture is the expensive one. Its 3200px PNG was 4.2 MB. JPEG60 brought that to 477 KB, and lossy WebP to 487 KB. The UI and code fixtures were already much easier for PNG to compress because they contain large flat areas and repeated shapes.

The second pattern is less obvious: at full size, JPEG85 was 19.8% larger than PNG for the UI fixture and 21.3% larger for the code fixture. JPEG85 was 81.3% smaller than PNG for the visual fixture. The same quality number did not produce the same size relationship across image content.

The third pattern is why I would not promise that resizing always creates a smooth size curve. Lossless WebP grew from 57,702 bytes at 3200px to 65,356 bytes at 1600px for the UI fixture. It grew from 64,946 bytes to 84,524 bytes for the code fixture. At 800px it became smaller again. The encoded size depends on the pixels left after resampling, not only on the width.

What “without losing quality” can mean

There are two different operations here.

Resizing changes the reference. A 3200 × 1800 capture resized to 1600 × 900 is a new image. Even a lossless WebP cannot restore the pixels that were removed during resampling.

Lossless encoding preserves the resized reference. In this study, all 18 optimized PNG outputs and all 18 lossless WebP outputs were pixel-identical to the same-size uncompressed reference. The 54 lossy JPEG/WebP outputs were not pixel-identical by design.

Pixel equality is useful for proving what the encoder changed. It is not a readability score. I did not run OCR, measure whether a person could read every label, or test a preview slider. A screenshot can be pixel-different and still be perfectly usable; it can also be pixel-identical and still be too small for the destination.

A practical Mac workflow

Apple’s Preview documentation gives you the basic controls without installing another app.

1. Open a copy in Preview.
2. Use Tools → Adjust Size and keep proportional scaling enabled.
3. Choose an image-pixel width that accounts for the display. For example, 1600 image pixels can supply an 800-CSS-pixel column at 2× density. Screen pixels and CSS pixels are different units; MDN explains that ratio.
4. Use File → Export to choose the output format and quality.
5. Inspect the smallest text at the actual display width. If the image is going into a document or issue tracker, check it there too.

If only part of the screenshot matters, crop first. A separate crop of our code fixture went from 3200 × 1800 to 1752 × 958 pixels and from 208,997 to 117,031 bytes—44.0% smaller—while keeping the remaining pixels at their original scale. It removes surrounding context, so keep the original available.

For repeated work, macOS’s sips command can resample a copy from Terminal:

sips --resampleWidth 1440 screenshot.png --out screenshot-1440.png

The command was checked on our owned PNG and produced 1440 × 810 pixels. It is separate from the 90-export matrix. Preview’s quality slider and sips JPEG encoding were not benchmarked.

Which format I would choose

If exact pixels, transparency, or crisp interface text are the priority, start with optimized PNG or lossless WebP. Confirm that the destination accepts WebP before using it. In this study, both were pixel-identical to the resized reference, but they produced different byte sizes for different fixtures.

If the screenshot is a color-heavy report or illustration, test JPEG or lossy WebP. They produced the biggest reductions on the visual fixture. Do not carry the same quality number from one codec to another as if it were a shared visual scale.

If the screenshot is a dense UI or code editor at full Retina width, do not assume JPEG85 is the efficient middle ground. It was larger than PNG for both text-heavy fixtures in this run. Choose the required detail and display density, then compare a lossless option with a lossy one at that image-pixel width.

The useful decision is therefore about the destination:

The strongest result from this study is not a winning codec. It is that content type and target width changed the answer. Keep your original, resize deliberately, and measure the file you are about to send.

Method and limits

The valid run used three synthetic fixtures, two fresh Chrome captures per fixture, three output widths and five export profiles. All 45 repeated export pairs matched exactly. The input fixtures contain no customer data and are not a representative photo corpus.

This study does not measure OCR, human readability accuracy, Preview’s quality slider, chat or documentation-platform recompression, photography, transparency behavior, color-profile retention, macOS keyboard screenshots, third-party capture apps, or AI recognition. Numeric quality settings are not cross-codec equivalent. The sources below document the workflows and formats; they do not turn this owned fixture run into a universal benchmark.

Sources

• Apple Preview: Resize, rotate, or flip an image
• Apple Preview: Export images
• Google WebP documentation
• Pillow image file formats
• Study protocol, results CSV and export receipt