Utility

The Math Behind Not Stretching Your Images When You Resize Them (2026)

Guessing at the second dimension when resizing is how stretched images happen. Here's the actual cross-multiplication and GCD math to get it exactly right.

📅 Sep 8, 2026·⏱️ 4 min read·✍️ Cikal Studio Labs
📐

Guessing the second dimension is how images end up distorted

Resizing an image to a target width while entering an approximate or rounded height — rather than the mathematically exact proportional value — is one of the most common causes of a visibly stretched or squashed image, since even a small deviation from the true ratio becomes noticeable, especially in images with straight lines or recognizable shapes like faces.

The actual math: cross-multiplication, not estimation

The correct proportional height for a new width is computed as: newHeight = newWidth × (originalHeight / originalWidth) — a straightforward but exact cross-multiplication that, done correctly, guarantees the resized image maintains precisely the same aspect ratio as the original, with zero distortion.

Why simplifying the ratio itself requires GCD, not casual reduction

Reducing a resolution like 3840×2160 to its simplest ratio form (16:9) requires finding the actual greatest common divisor of both numbers — a manual or approximate reduction can produce an unreduced or incorrect simplified ratio, whereas the Euclidean GCD algorithm guarantees the mathematically simplest correct form every time.

Why rounding to a whole pixel still matters for pixel-perfect work

The exact mathematical result of a proportional resize calculation is rarely a whole number — a real-world resize has to round to the nearest whole pixel, which introduces a tiny, usually negligible deviation from the true ratio. For most use cases this doesn't matter, but for pixel-perfect export work (sprite sheets, precise UI assets), knowing exactly how much rounding drift was introduced is worth surfacing rather than silently ignoring.

Working bidirectionally solves a common real-world need

Sometimes the known constraint is a target width (fitting a page layout), and sometimes it's a target height (fitting a fixed banner slot) — a calculator that solves correctly in either direction, from the same original aspect ratio, covers both real scenarios without requiring a separate calculation or tool for each.

Frequently Asked Questions

What's the actual formula used to compute the correct proportional dimension?

newHeight = newWidth × (originalHeight / originalWidth) — a straightforward but exact cross-multiplication that guarantees the resized image maintains precisely the original aspect ratio with zero distortion, unlike a rounded or estimated guess.

How does the tool simplify a ratio like 3840×2160 down to 16:9?

It computes the actual greatest common divisor (GCD) of both numbers using the Euclidean algorithm, then divides both dimensions by that GCD — guaranteeing the mathematically simplest correct ratio form, rather than a manual or approximate reduction that could be wrong or unreduced.

Why does the tool flag when a computed dimension isn't a whole pixel?

The exact mathematical result of a proportional resize is rarely a whole number, and rounding to the nearest whole pixel introduces a tiny, usually negligible deviation from the true ratio — for pixel-perfect export work, knowing the exact drift is worth surfacing rather than silently ignoring.

Can I solve for width given a target height, or only the other way around?

Both — entering a new width calculates the correct proportional height, and entering a new height calculates the correct proportional width, from the same original aspect ratio.

Is any of my image dimension data sent anywhere?

No. All calculation happens locally in your browser — no image file or dimension data is uploaded or logged anywhere.