Resize image by percentage

You provide the original width and height plus the percentage, and it returns the resulting dimensions rounded to whole pixels, along with the final megapixel count. It is pure arithmetic — no image is uploaded, processed or stored — so it runs instantly in your browser and identically through the API when you need it inside a build script, a thumbnail pipeline or a layout calculation that has to know the exact box an image will occupy before it exists.

Why percentage resizing is deceptively simple

Scaling an image to a percentage looks like one multiplication, but the details decide whether your layout breaks. Each side must be scaled independently and rounded to a whole pixel, because there is no such thing as 640.5 pixels. Round 1920 by 33 percent naively and you get 633.6, which no renderer accepts; this calculator returns 634. The rounding rule matters most on small images: shrinking an 11-pixel icon to 15 percent yields 1.65 pixels, and the honest answer is 2, not a truncated 1 that silently distorts the aspect ratio. Getting these numbers before you touch the image lets you pre-allocate the right canvas size in a thumbnail job, write the correct width and height attributes into your HTML so the page does not reflow when the image loads, and verify that a batch resizer produced what you asked for. The resize image by percentage tool does exactly this math, deterministically, so the answer you see in the browser is byte-for-byte the answer the API returns to your code.

How the calculation works

The formula is one line per dimension: new side equals original side times percentage divided by one hundred, rounded to the nearest whole pixel. A percentage of 50 halves the image, 100 leaves it unchanged, and 250 scales it up two and a half times. Both width and height use the same factor, which is what preserves the aspect ratio — apart from the sub-pixel rounding error that is unavoidable when whole pixels cannot express the exact ratio. The result also includes the megapixel count of the output, which is the number that actually predicts file size and memory cost: scaling to 50 percent does not halve the pixels, it quarters them, because area grows with the square of the sides. The percentage must be positive; zero or a negative value is rejected as invalid input rather than silently producing a zero-dimension image, and a computed side can never fall below one pixel. Every example on this page was generated by running the real handler, so what you read is what you get.

Where it fits in a real workflow

Front-end developers use it to compute responsive srcset entries: from a 2400-pixel master, the 25, 50 and 75 percent variants come out at 600, 1200 and 1800 pixels, and those numbers go straight into the markup. Designers use it when a client asks for a photo at 30 percent for a newsletter and someone has to confirm the result still meets the email template's minimum width. Backend engineers call the API inside pipeline checks, comparing the dimensions a resizer produced against the dimensions it should have produced, and failing the job when they disagree. Because the capability is pure math with no file handling, it costs nothing to run many times: the browser version on this page is free and unlimited, and the API charges only $0.002 per call when you automate it. If you need the pixels themselves transformed rather than the dimensions computed, that is a different capability; this one exists so the planning step is exact, fast and cheap enough to run on every image in the batch.