gizmobench
BrowseDaily
← All guides

GizmoBench guides

5 Step Image Compression Workflow: Resize First, Use No Upload Tools

GizmoBench ·

Keep an untouched master, resize the image to its actual display size, pick a format that fits the content (photos favor lossy WebP or AVIF, graphics favor PNG or lossless WebP), export with conservative starting settings, and check the result at real size before you publish. For a one-off image, a browser tool handles this in a minute; for batches, command-line utilities like vips or sharp do the same job at scale.

TL;DR:

  • Resizing images before compression significantly reduces file size and encoding time, especially when the display size is smaller than the original resolution.
  • Lossless formats like PNG are ideal for images with sharp edges or transparency, while lossy formats like JPEG and WebP suit photographs, but should be tested to find the best balance between quality and size.
  • Choosing the appropriate format depends on the content: JPEG for photos, PNG for graphics, WebP for versatile use, AVIF for aggressive compression, and SVG for vector graphics.
  • Always verify the final image at real display size, inspecting details like text clarity and edge sharpness, to prevent visible artifacts and ensure quality preservation.
  • Use responsive image techniques with multiple sizes and formats, including fallback options, to optimize delivery across different devices and prioritize efficient loading.
GizmoBench
gizmobench.com
Resize Images Directly In Your Browser
GizmoBench offers practical image tools that help you resize and process files locally, without an account or software installation.
Open image tools

Table of Contents

How image compression works and why the subject matters

Compression falls into two categories, and confusing them is the fastest way to ruin an image. Lossless compression rearranges data more efficiently without discarding any pixel information, so decompressing the file returns exactly what you started with. Lossy compression throws away information the algorithm judges unnecessary, trading some fidelity for a smaller file. A screenshot with crisp text compresses well losslessly because every pixel matters; a landscape photograph tolerates lossy compression because small changes in a leaf or a cloud go unnoticed.

Most lossy formats rely on chroma subsampling and block-based transforms. Chroma subsampling reduces color detail while keeping brightness detail, since human vision is more sensitive to brightness than to color, and it works well on photos but can smear the edges of colored text. Block transforms split the image into small tiles, compress each one, and reassemble them, which is efficient for smooth photographic gradients but tends to create visible blockiness or ringing around sharp edges, a pattern you will notice most online art, logos, and screenshots.

Format choice follows directly from this. According to MDN’s image format guide, the right choice depends on the subject rather than habit.

  • JPEG suits photographic images where broad compatibility matters and small lossy artifacts are acceptable.
  • PNG suits screenshots, diagrams, line art, and anything needing transparency or exact pixel preservation.
  • WebP offers both lossy and lossless modes with broad support, making it a practical default for many web images.
  • AVIF compresses aggressively and supports transparency, animation, and high bit depth, though it costs more to encode and needs a fallback for older browsers.
  • SVG fits logos, icons, and other vector graphics that should scale without any resolution loss at all.

Step-by-step workflow: prepare, resize, choose format, export, verify

The sequence matters more than any individual setting. According to Web, the biggest practical mistake is compressing an image before resizing it: a large photo displayed at a small size still forces the browser to download and decode the full original, no matter how aggressively you compress it afterward.

  1. Identify the destination and its maximum display dimensions, whether that is a blog header, a product thumbnail, or a print layout.
  2. Resize or crop first, so you are compressing an image at the size it will actually be shown, not its original camera or scan resolution.
  3. Choose a format suited to the content, photographic or graphic, using the JPEG, PNG, WebP, and AVIF guidance above.
  4. Lower the quality setting while inspecting the result at real display size, rather than trusting a single default number.
  5. Reopen the exported file and verify it, checking both visual quality and the final file size before you publish or hand it off.

For advanced workflows, the same five steps apply but run through a script instead of a dialog box. Batch pipelines benefit from checkpoints: resize once, encode to a test format at a mid quality setting, spot-check a sample, then run the full batch. Encoding speed and output size trade off against each other, so a pipeline processing thousands of images may prefer a faster encoder even if a slower one saves a few extra kilobytes per file. Always keep the original, unprocessed files in an archive folder separate from the exported versions, since lossy exports cannot be reconstructed back into their source quality.

Pro Tip: Resizing before compressing is the single biggest byte-saver in this entire workflow, and it also shortens encoding time, since the encoder processes far fewer pixels.

Format-specific export guidance and starting settings

Starting from sensible defaults saves a lot of trial and error, though every image still deserves a visual check afterward. Guidance from Google’s Optimize Images documentation offers concrete starting points rather than fixed rules.

  • JPEG: start near quality 85, apply 4:2:0 chroma subsampling where the content allows it, and use progressive encoding for files over 10 kilobytes so the image loads in successive passes.
  • PNG: reserve it for graphics with sharp edges, text, or transparency, and strip unused alpha channels and embedded metadata that add bytes without adding visible information.
  • WebP: test both lossy and lossless modes on the same image, since the better choice depends on content, not on a fixed rule.
  • AVIF: often compresses more tightly than WebP or JPEG at equivalent visual quality, but it encodes more slowly and needs a fallback format for browsers that do not support it yet.

A quality setting of 85 is not universal across codecs. JPEG quality 85 does not mean the same thing as WebP or AVIF quality 85, since Google’s guidance frames these as starting points to verify visually, not values that transfer directly between formats.

If you are automating exports with command-line tools, benchmark encoder settings against your own image set before locking in defaults for a whole pipeline. A setting that looks fine on a test photo can behave differently on a busy pattern or a low-light shot.

Serving images: responsive sizes, formats, and layout stability

Compression alone does not solve delivery; for tips on how to share large files effectively, see our guide to sharing large video files without losing quality. A correctly compressed image can still waste bandwidth if a phone downloads the same file meant for a desktop monitor. The srcset and sizes attributes let the browser pick the best candidate from a set of width variants, and web.dev’s guide to responsive images recommends this over relying on a single fixed size for every device.

  • Create three to five width variants of each important image as a practical starting rule, covering common breakpoints from mobile to desktop.
  • Use the picture element with type attributes to offer AVIF or WebP first and fall back to JPEG, so browsers request only the format they can decode.
  • Add explicit width and height attributes to every image tag, which reserves space in the layout and prevents content from jumping around as images load.
  • Lazy-load images below the fold so the browser defers requests for content the visitor has not scrolled to yet.

None of this replaces compression itself. It complements it by making sure the well-compressed file also reaches the right device at the right size.

Tools and automation: interactive editors versus batch encoders

For a single image, an interactive tool is faster than writing a script. Squoosh lets you compare formats and quality settings side by side in the browser before exporting, and GizmoBench’s Image Resizer runs entirely in the browser with no upload step, which is convenient for a quick resize before you compress elsewhere. Neither tool needs an account for its core function.

For repeated or large batches, command-line tools scale better than clicking through a dialog box for every file.

  • ImageMagick handles broad format conversion and scripting for mixed batches.
  • vips (via libvips) processes large images with a small memory footprint, useful for high-resolution source files.
  • sharp wraps libvips for Node.js pipelines, common in automated build steps.
  • MozJPEG and cwebp are dedicated encoders that often outperform generic tools on JPEG and WebP output specifically.

Pro Tip: Before locking in a pipeline, encode the same sample image set through each candidate tool and compare both file size and encoding time, since the fastest option and the smallest output are rarely the same tool.

Verification: visual checks, objective metrics, and archiving

A compressed file is only good if it looks right at the size it will actually be viewed. Inspect the export at its real display dimensions on the devices your audience is likely to use, paying particular attention to text, edges, and areas of fine detail like hair or fabric texture, since these show artifacts first. Compare the compressed version side by side with the original, and confirm that color profiles and transparency survived the export intact.

  • Check text and sharp edges for blockiness or ringing, the clearest sign of over-compression.
  • Compare side by side at real size, never at a zoomed-in crop that exaggerates or hides artifacts.
  • Confirm color profile and transparency were preserved through the export.
  • Check the metadata to confirm what was kept or stripped.

Objective metrics like SSIM offer a repeatable score for comparing settings, according to the MDN blog’s coverage of image codecs and compression tools, though visual inspection at target size often catches artifacts a metric alone will miss. Once you settle on export settings, archive the lossless master separately and avoid re-saving a lossy file repeatedly, since each additional lossy pass compounds quality loss.

What happens to metadata when you compress an image

Most image files carry more than pixels. EXIF data records camera settings, timestamps, and sometimes GPS coordinates; ICC color profiles describe how colors should render on a display; XMP fields can hold copyright or caption information. Many compression tools strip some or all of this metadata by default, which is often desirable since metadata adds bytes without changing what the image looks like on screen.

Illustration of image metadata layers

Stripping metadata is not always harmless, though. A color profile mismatch after export can shift colors slightly on some displays, so it is worth confirming the profile survived if color accuracy matters, for example in product photography or print-bound work. Copyright and attribution fields in XMP or IPTC data matter for photographers who rely on that information traveling with the file; stripping them removes a layer of provenance that is hard to restore later. GPS coordinates embedded in EXIF data are a privacy consideration worth checking before sharing personal photos publicly, since many phones record location by default.

The practical approach is to decide what you need before you export: strip GPS and unnecessary EXIF fields for web images where file size matters most, but preserve color profiles for anything where color accuracy is important, and keep copyright metadata on any image you plan to distribute under your own name. Most export tools let you choose what to keep rather than forcing an all-or-nothing decision.

How compression choices affect accessibility

Compression settings interact with accessibility in ways that are easy to overlook. Over-compressing an image with fine detail, such as a chart, a diagram, or a screenshot with small text, can blur or blockify content that low-vision users already need extra clarity to read. Choosing a lossless format like PNG for text-heavy graphics, rather than pushing a lossy JPEG to a low quality setting, preserves the sharp edges that make small text legible on assistive display modes and screen magnifiers.

Compression itself does not replace alt text, and the two work together rather than as substitutes. An image compressed well but missing a meaningful alt attribute is still inaccessible to a screen reader user, since alt text is what gets read aloud or announced, not the pixel content. Conversely, a well-written alt attribute on a badly compressed, illegible chart still leaves sighted low-vision users without a usable image. Treat format choice and quality settings as one part of an accessible image, with descriptive alt text as the other, non-negotiable part.

Common pitfalls that produce visible compression artifacts

Most compression problems trace back to a small set of repeatable mistakes. Recognizing them in your own exports saves time compared to guessing at settings blindly.

  • Compressing before resizing wastes the encoder’s effort on pixels that will be scaled down anyway, and it produces a larger file than resizing first would.
  • Re-saving a lossy file repeatedly compounds quality loss with every pass, since each JPEG re-save re-quantizes data that was already approximated.
  • Applying a uniform quality setting across very different images ignores that a busy photo and a flat-color graphic need different treatment entirely.
  • Using JPEG for text, line art, or screenshots introduces blockiness and color bleeding around edges that a lossless format would have avoided.
  • Ignoring chroma subsampling on images with colored text or fine color detail can cause color fringing that a quick visual check would have caught.

The common thread is skipping verification. Every one of these mistakes is visible the moment you inspect the exported file at real display size, which is why that step belongs at the end of every workflow, not as an occasional afterthought.

Balancing file size and load performance across contexts

The right trade-off between file size and quality depends heavily on where the image will be viewed. According to web.dev, images are often among the heaviest resources on a page, and reducing transferred bytes has a direct effect on loading performance metrics like Largest Contentful Paint. Serving a desktop-sized image to a mobile device can transfer two to four times more data than the device actually needs, which is one reason responsive width variants matter as much as compression settings themselves.

For a web hero image or a product photo, the priority is usually the smallest file that still looks sharp at its rendered size on the devices your visitors actually use. For a print-bound image, the priority flips: print needs the full-resolution master, and compression should be light or entirely lossless, since print resolution requirements are far higher than any screen. For a mobile app icon or a favicon, small fixed dimensions mean the file size is already tiny, so quality can stay high without a real byte cost. There is no single number that fits every context; the workflow of resizing to the actual output target first, then compressing and verifying, is what keeps the trade-off sensible regardless of where the image ends up.

Try GizmoBench’s browser tools for quick resizing and color checks

You do not need to install software or create an account to handle the one-off parts of this workflow. GizmoBench’s Image Resizer runs locally in your browser, resizing an image to your target dimensions without uploading the file anywhere, which fits the resize-before-compress step directly. The Image Color Picker samples exact hex values from an image, useful for confirming color consistency after export, and the Favicon Generator turns a source image into the small icon sizes a site needs without a separate design pass.

These tools handle the interactive, one-off side of the job well, though they are not a substitute for a scripted batch pipeline if you are processing hundreds of images at once. For that broader catalog of everyday utilities, GizmoBench’s tools page is worth a look.

Sources

FAQ

What is the best starting quality setting for JPEG images?

A quality setting near 85 with 4:2:0 chroma subsampling is a reasonable starting point for most photographic JPEGs, according to Google’s Optimize Images guidance. Always inspect the result at real display size afterward, since the right setting varies by image content.

Should I use WebP or AVIF for my website images?

Both are strong choices over older JPEG and PNG formats, and the right one depends on your compatibility needs and encoding budget. AVIF often compresses more tightly than WebP for equivalent visual quality, according to MDN’s coverage of image codecs, but it encodes more slowly and needs a JPEG or WebP fallback for older browsers.

Does compressing an image remove its metadata automatically?

Many compression tools strip EXIF, GPS, and other metadata by default, though this varies by tool and export setting. It is worth checking your export settings directly if you need to preserve color profiles or copyright information, since not every tool handles this the same way.

Why does my compressed image look blocky around text or edges?

Blockiness around sharp edges usually means a lossy format like JPEG was used on content that needed lossless compression, such as text or line art. Switching to PNG or lossless WebP for that kind of graphic, rather than pushing a lossy quality setting lower, generally resolves the artifact.

Do I need to resize an image before compressing it?

Yes, resizing to the image’s actual display dimensions before compression is the most effective single step for reducing file size, according to web.dev’s image performance guide. Compressing a large image that will only display at a small size still forces a full-size download and wastes encoding effort.