Resize vs compress: pixels and kilobytes are different things

“Resize image to 50 KB” is one of the most-searched phrases in this whole topic, and it contains a category error that causes real upload failures. Resizing and compressing are different operations that control different numbers. Forms often check both. Once you see the distinction, every portal requirement becomes readable.

The two numbers

Dimensions are the image’s width and height in pixels — say 1200 × 900. They determine how big the image looks and how much detail it can possibly hold. Requirements written in pixels (630 × 810 px) or centimetres (3.5 × 4.5 cm) are dimension requirements.

File size is how many bytes the image occupies on disk — say 250 KB. It determines storage and transfer cost. Requirements written in KB or MB are file-size requirements.

The two are related but loosely: a 1200 × 900 photo might weigh 80 KB or 800 KB depending on format, compression quality and how much detail the scene contains. A busy forest scene needs far more bytes than a face against a white wall at the same dimensions and quality.

What resizing does

Resizing changes the pixel grid: a 4000 × 3000 photo becomes 1000 × 750. Detail beyond the new grid is gone — permanently, but predictably. Resizing usually shrinks the file too, roughly with the pixel count: quarter the pixels, roughly quarter the bytes. But you can’t hit a byte target by resizing alone, because the relationship is approximate.

What compressing does

Compression (in lossy formats like JPEG and WebP) keeps the pixel grid and instead stores it less faithfully — smoothing subtle textures the eye barely notices. Quality 90 keeps almost everything; quality 30 visibly smudges. Compression is how you control bytes without changing how large the image displays.

Why forms check both

A portal that wants a passport photo needs:

• the right shape and detail level → a dimension rule (3.5 × 4.5 cm proportions, or exactly 630 × 810 px), and
• a bounded storage cost → a file-size rule (under 250 KB, or a 20–50 KB band).

Pass one check and fail the other, and you’re rejected either way. This is the single most common confusion behind “but I already made it smaller!” frustration — the user resized when the form wanted compression, or vice versa.

How to hit both targets at once

The right order of operations:

1. Crop to the required shape (don’t stretch — a distorted face fails human review).
2. Resize to the required or sensible dimensions.
3. Compress to just under the byte target, at the highest quality that fits.

Doing this manually means bouncing between an editor and a file manager, checking sizes, re-exporting. Our compressor does the loop for you: it binary-searches the quality setting against your KB target, and if no quality fits, steps the dimensions down and tries again. The portal presets set both rules at once — the SSC preset, for example, produces 413 × 531 px and 20–50 KB in one click.

Rules of thumb worth keeping

• Match dimensions to actual use. Screens rarely display more than ~1200 px of image width; form photos are displayed at a few hundred pixels. Extra pixels beyond that spend your byte budget on detail nobody will ever see.
• A KB target implies a dimension range. 20 KB supports a clean face photo at ~400–500 px, not at 4000 px. If the quality looks bad at your target, the dimensions are too large for the byte budget.
• Never enlarge. Scaling a small image up adds bytes and blur, and portals’ human reviewers reject blur. If your source is too small, get a better source.
• PNG resizes, JPEG compresses. PNG has no quality dial — its size is controlled by pixels alone. That’s why a “compress PNG” tool is really a resize tool, as explained in JPEG vs PNG vs WebP.

Once the two numbers separate in your head, requirement text stops being confusing: “3.5 × 4.5 cm, 20–50 KB, JPEG” reads as crop to this shape, then compress into this band, in this format — three operations, in that order, all local, all under your control.