Resize when a requirement concerns pixel dimensions; compress when it concerns encoded file size. Sometimes you need both. First identify what “smaller” means for your upload, then check the actual output against that requirement.

A form asking for a maximum width of 1200 pixels is setting a different limit from one asking for a file below a byte ceiling. Meeting either limit does not automatically meet the other. Keep the original so you can make another version without repeatedly editing an already reduced copy.

What does “image size” mean?

Pixel dimensions: width × height

Pixel dimensions describe the image grid. A 4000 × 3000 image contains 12,000,000 pixels. That count tells you how many pixel positions exist, but does not determine the encoded KB or MB needed to store them.

The word “resolution” is ambiguous: it can mean pixel dimensions or a print-density concept such as pixels per inch (PPI). A print-density label is not an upload-width measurement. Check whether the requirement names pixels, bytes, or physical print dimensions before changing anything.

File size: bytes, KB, and MB

File size is the number of encoded bytes in the saved file. Those bytes represent compressed image information and may include metadata. A highly detailed scene and a flat background can have identical dimensions yet need different amounts of storage.

Interfaces do not all use KB and MB with the same decimal or binary convention. For the experiment below, we give exact bytes and KiB, where 1 KiB equals 1024 bytes. When a service sets a strict limit, use its stated units and verify the downloaded file rather than relying on a rounded label.

What resizing changes

Fewer pixels, different detail

Here, resizing means changing pixel width or height. Downsampling rebuilds the image on a smaller grid and removes spatial information. Fine lettering, narrow lines, and small textures may become less distinct. Ordinary enlargement estimates additional pixels; it does not recreate genuine detail missing from the source.

Halving both dimensions leaves one quarter of the pixels: 2400 × 1600 becomes 1200 × 800, dropping from 3,840,000 to 960,000 pixels. This arithmetic describes the grid, not the encoded file size. Adobe’s explanation of resizing and resampling distinguishes pixel changes from changes to print size.

Why a resized file is not predictably smaller

Saving the new grid can also involve re-encoding. The source’s existing compression, the encoder, settings, and image content all affect the result. One quarter of the pixels does not guarantee one quarter of the bytes, and a resized file is not guaranteed to be smaller.

For an upload-width limit, resize to appropriate dimensions and inspect the saved result. If its file size is still too large, that is a separate constraint to address. Keeping the aspect ratio avoids unintended stretching when you only need a smaller version.

What compression changes

Lossy and lossless compression

Compression can reduce encoded bytes without changing width or height. Lossy compression discards some image information; lossless compression represents information so it can be recovered exactly. The PNG specification, for example, defines a lossless image format. That does not mean every surrounding editing operation preserves the original pixels or metadata.

Same dimensions, different file sizes

Two JPEGs can both be 2400 × 1600 while containing different pixel values and different byte counts. Compression results depend on source content, format, and settings. An already efficient file may offer little saving, and a fresh encoding can even be larger.

A quality setting controls an encoder; it is not a target file size or a universal quality measurement. The number 85 does not mean “85% of original quality.” Check appearance and byte size separately instead of treating that number as a promise.

One image, four measured outcomes

Source and settings

We created this original synthetic still life for the experiment: a vase, leafy stems, an orange, a notebook, and a mug. It combines smooth gradients, solid regions, fine edges, and moderate deterministic texture. No photograph, stock asset, or font was used.

Original synthetic still-life illustration used for the comparison: a teal vase with leafy stems, an orange, a notebook, and a mug on a wooden tabletop.
Synthetic source created by Savezly for this experiment. Measurements use the retained 2400 × 1600 JPEG. This web preview may be optimized by the site’s CDN and is not the file used to verify byte measurements. It is not a full-resolution quality comparison.

The 2400 × 1600 canvas master was encoded once as JPEG at quality 0.95 and frozen before testing. We then used the actual Savezly tools: Compress at 85, Resize to width 1200 with aspect ratio locked and fixed JPEG quality 0.90, and Compress at 85 on the actual Resize download.

The measurements used Chromium 151.0.7922.34 on Windows, through its browser canvas JPEG encoder. The retained reproduction record includes exact files, hashes, settings, and tool revision. Other browser engines are not established to produce identical bytes.

Results and their limits

One frozen JPEG through four workflow states; KiB rounded to three decimals
WorkflowSettingsDimensions / pixelsMeasured file sizeBytes reduced vs original
OriginalCanvas JPEG quality 0.95 2400 × 1600
3,840,000 pixels
252,914 bytes
246.986 KiB
Baseline
Compress onlyJPEG quality 85; dimensions unchanged 2400 × 1600
3,840,000 pixels
152,626 bytes
149.049 KiB
39.65%
Resize onlyWidth 1200 px; aspect ratio locked; fixed JPEG quality 0.90 1200 × 800
960,000 pixels
64,698 bytes
63.182 KiB
74.42%
Resize then CompressResize download → JPEG quality 85; dimensions unchanged 1200 × 800
960,000 pixels
57,192 bytes
55.852 KiB
77.39%

These results describe this one synthetic source and these exact settings. Different images can produce very different byte savings. Resize-only re-encoded the JPEG: it was not a pure dimension-only byte experiment. Resize → Compress added another lossy JPEG encoding pass. Quality 85 does not mean 85% retained quality, and dimensions alone do not predict encoded bytes. This example is illustrative, not a benchmark or guarantee.

Both Compress runs offered downloads under the real savings rule: at least the greater of 1024 bytes or 1% of the input size, rounded up to whole bytes. If a candidate fails that rule, Savezly offers no download; an unaccepted candidate should not be counted as a usable tool result.

Should you resize, compress, or do both?

Match the operation to the actual requirement
RequirementReasonable next step
Maximum 1200 px widthResize if wider; keep proportions unless different dimensions are required. Check the resulting width.
Dimensions acceptable, byte limit exceededTry compression, then check file size and appearance.
Same dimensions mandatory; smaller transfer or storage file wantedTry compression without resizing. Savings are not assured.
Source much larger than intended display dimensionsConsider resizing for the actual display need, allowing for display density and any zoom use.
Both dimension and byte limits exceededResize first, inspect the saved bytes, then compress if still needed.
Exact maximum byte size requiredVerify the actual output against the ceiling. Savezly Resize and Compress do not guarantee a target KB/MB size.
PPI or display-size confusionClarify the units. A PPI label or smaller on-screen preview does not establish fewer encoded bytes.
Every original pixel must remain intactKeep the original. Avoid resampling and lossy re-encoding; use a verified lossless workflow if optimization is needed.

What “without losing quality” can mean

Identical pixels versus acceptable appearance

Visually acceptable is not the same as pixel-identical. A smaller file may look suitable at its intended display size while differing under close inspection. Examine fine edges, gradients, and important small details. A preview reduced to fit a page cannot establish equivalence at full size.

Avoid unnecessary lossy re-encoding

Repeated lossy saves can accumulate changes and artifacts. Work from the original when trying alternatives, and avoid extra encoding passes once the requirement is met. Adobe’s JPEG optimization guidance explains the size/detail tradeoff and degradation from repeated JPEG saves. The combined workflow above illustrates an additional pass, not a recommendation to always perform one.

Choosing a Savezly tool

Use Resize to resize an image’s pixel dimensions by pixels or percentage, with aspect ratio locked by default. It retains the format; JPEG/WebP encoding uses fixed quality 0.90. Output is not guaranteed smaller.

Use Compress to compress an image while keeping its dimensions. JPEG/WebP quality runs from 60 to 95 in steps of 5, default 85. PNG uses local OxiPNG optimization and ignores the quality slider. Compress does not automatically resize, crop, or convert; downloads require the savings threshold above.

Both accept JPEG/JPG, PNG, and static WebP, not animated WebP: up to 20 files, 20 MiB each, 50 MiB combined, 8192 pixels per side, and 16 million pixels per image. Selected images are processed locally in your browser and are not uploaded to Savezly or a remote image-processing service. Metadata representation may change during decoding, re-encoding, or optimization.