Image Resizer

Choosing a mode

Fit is the everyday answer: give it the largest box the destination allows (say 1200×1200) and every image scales to sit inside while keeping its shape — an illustrative 4032×3024 photo lands at 1200×900. Exact is for pipelines that demand specific pixels — thumbnails, avatars, sprite sheets — and will stretch unless you tick the aspect lock, which derives the height from your width automatically. Percent maps directly to intent like "half size": 25% of that same photo is 1008×756. These worked figures are computed at build time by the same engine that resizes your files, so the copy cannot drift from the code.

Guide: Resizing math. This page shows what the resizer decides for a given request; the guide works the arithmetic behind every mode step by step — the fit ratio, the aspect lock, percent scaling, the rounding rule, the 1-pixel floor and the output caps — on the same kind of illustrative dimensions. Read it when you want to predict a result before dropping a file.

What the plan decides — worked on illustrative dimensions

Behind the three radio buttons sits one pure function: source width and height plus a request go in, and a plan comes out — target width and height, a flag for enlargement, and a list of warnings. No pixel is touched until the plan exists. Every figure in the table is that function's output at build time for an invented 4032×3024 landscape photo, an invented 1080×1920 portrait, and a handful of edge cases chosen to show the rounding and the floor. None of them is typed by hand.

Mode	Request	Source	Plan	Flagged
Fit	1200×1200 box	4032×3024	1200×900	nothing
Fit	1200×1200 box	1080×1920	675×1200	nothing
Exact, lock on	width 1600	4032×3024	1600×1200	nothing
Exact, lock off	1200×1200	4032×3024	1200×1200	nothing — shape changed
Percent	25%	4032×3024	1008×756	nothing
Percent	50%	1001×1000	501×500	nothing — rounded
Fit	100×100 box	10000×10	100×1	nothing — 1-pixel floor
Fit	1280×1280 box	640×480	1280×960	enlargement
Percent	150%	7000×5000	10500×7500	2 warnings

Fit computes one scale factor, the smaller of box-width over width and box-height over height, and applies it to both sides. The box is a ceiling, not a canvas: the landscape photo comes out 1200×900, not padded to 1200×1200, and the portrait is governed by its height, so it comes out 675×1200. Fit never crops; the whole source is drawn.

Exact with the lock on runs a second small function first: the height that preserves the source ratio for the width you typed. For the 4032×3024 photo and a width of 1600 that is 1200, so the plan becomes 1600×1200. Exact with the lock off hands your two numbers straight through: 1200×1200 from the same photo is 1200×1200, a square made from a 4:3 image. The plan records no distortion — its enlargement flag is not set because neither dimension exceeds its source counterpart — so the only check on a changed shape is you.

Percent is a linear scale on each side, which is worth spelling out. 25% of 4032×3024 is 1008×756: each side is a quarter, which leaves 762,048 of the original 12,192,768 pixels — 6.25% of them, not 25%. Dimensions round to whole pixels: 50% of 1001×1000 is 501×500, because 500.5 rounds up. The floor is one pixel: a 10000×10 strip fit into a 100×100 box becomes 100×1 rather than collapsing to a zero-height image, as the methodology page states.

Limits, warnings and refusals — in the engine's own words

Three constants bound every plan. Outputs may not exceed 16,384 pixels per side or 80 megapixels overall, and a plan above 50 megapixels carries a performance warning. A refusal is an error on the file row with no download; a warning is a note on the row and the download still appears. The exact wording below is what the engine returned at build time for the illustrative requests named.

A 3000×2000 image asked for at 600% would be 18,000 pixels wide. Refused: "Output dimensions are limited to 16384 pixels per side (browser canvas limit)."
The same 3000×2000 image at 1001%. Refused before any arithmetic: "Scaling beyond 1000% is not supported."
A 7000×6000 image at 150% would be 10,500×9,000 — within the side limit, but 94,500,000 pixels. Refused: "Outputs are limited to 80 megapixels to keep the browser responsive."
A 7000×5000 image at the same 150% is allowed — 10,500×7,500, 78,750,000 pixels — and arrives with 2 warnings:
- "Enlarging beyond the original size cannot add detail — the result will be softer than the source."
- "Very large output (over 50 megapixels) — encoding may be slow or fail on low-memory devices."

Inputs are bounded before any plan is made, by the client's own limits as the methodology page states them: 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection. A selection over the file-count or total-size limit is refused as a whole before any file is read; an image over the per-file limits is reported on its own row and skipped while the rest of the batch proceeds.

What carries through a resize

Identity comes from bytes, not names. The first thing the tool does with a file is read its leading bytes and compare them with the format signatures — \x89PNG, FF D8 FF, RIFF…WEBP, GIF87a/GIF89a, BM. Run at build time on constructed bytes, the detector returns PNG for the 8-byte PNG signature and GIF for the ASCII GIF89a. The filename is then compared with that verdict: an invented holiday.png whose bytes begin FF D8 FF is JPEG claimed as PNG, a mismatch the row states plainly. The resize runs on the JPEG content and the download is named holiday.jpg.

Format passes through where the browser can write it. This page writes PNG, JPEG or WebP — the format it read where that is one of the three, PNG otherwise. PNG stays PNG, which the engine's capability table marks as lossless; JPG stays JPG, re-encoded by the browser's own encoder at the table's default quality of 0.92 on the canvas 0–1 scale; WebP stays WebP at 0.85. This page exposes no quality control — those two defaults are the page's fixed settings, stated here rather than recommended, and the Image Compressor is where quality becomes a choice. GIF and BMP cannot be encoded by browsers, so their resized copies are written as PNG; the row says so. A HEIC file, which the picker does not list but the tool still reads, also comes back as PNG, because the site never encodes HEIC; the row says so in that case too. An animated GIF or WebP is recognised before decoding — image descriptors counted for GIF, the VP8X flag and ANIM chunks read for WebP — and only its first frame is resized, with the caveat on the row. AVIF is the exception worth stating. The tool accepts it because it accepts every format the engine decodes — PNG, JPEG, WebP, GIF, BMP, HEIC, AVIF — and the engine's plan for an AVIF source sets the first-frame flag (yes), so an avis image sequence carries the same note; but this page encodes only through the canvas as PNG, JPEG or WebP while expecting AVIF back, so the verification step finds the canvas's bytes where it expected AVIF and the row ends in a verification error rather than a resized AVIF. Convert first with AVIF to PNG or AVIF to JPG, then resize the result.

Filenames follow the format. The output name keeps your stem and swaps in the canonical extension; when nothing would change, a suffix stops the download shadowing the original. Computed at build time on invented names: holiday.jpg becomes holiday-resized.jpg, logo.png becomes logo-resized.png, while sticker.gif becomes sticker.png and scan.bmp becomes scan.png — no suffix, because the extension already differs.

Transparency is never flattened here. The capability table says PNG keeps alpha, WebP keeps it, and JPEG cannot hold it; since this page writes PNG, JPEG or WebP — the format it read where that is one of the three, PNG otherwise — no image moves from an alpha-capable format to one that cannot hold alpha, so no background colour is asked for and none is composited. A transparent GIF comes back as a transparent PNG.

Metadata does not carry through. Canvas re-encoding strips all embedded metadata: EXIF (including GPS location, camera model and timestamps), colour-profile tags and text chunks — a privacy feature when sharing, a caveat when you care about copyright fields or ICC profiles, so keep your originals. Orientation is applied during decoding, before the metadata is discarded, so a sideways phone photo resizes upright even though the orientation tag itself is gone.

How the output is verified

A download button on this page means three checks have already passed. The produced bytes are sniffed with the same detector applied to inputs, so a browser that silently wrote another format is reported as an error rather than handed to you as a mislabeled file. The blob is then re-decoded, and its pixel dimensions are compared with the plan's target width and height — a disagreement is an error, not a rounding note. Only then does the row show the verified format, the verified dimensions, and the output's true byte count beside the input's.

The percentage on a row is computed from those two measured byte counts for your file and nothing else. To show the wording without implying an expectation: on invented counts of 3,150,000 and 410,000 bytes the engine writes "87% smaller"; on invented counts of 48,000 and 61,000 it writes "27% larger — keep your original". Both are arithmetic on made-up numbers. The site publishes no blanket compression percentages, because no percentage is true for every image — and when a result comes out larger the row says "larger — keep your original" in the same breath.

Upscaling: allowed, flagged, never oversold

Making an image larger only spreads the same information across more pixels — interpolation, not enhancement. This resizer performs the enlargement when you ask and attaches a plain warning to the row, because sometimes a softer, bigger image is exactly what a slide deck needs. What it will not do is call it "AI upscaling" or promise recovered detail. The flag is set whenever either target dimension exceeds its source counterpart: a 640×480 image fit into a 1280×1280 box plans 1280×960 with enlargement flagged, and the row carries the engine's wording: "Enlarging beyond the original size cannot add detail — the result will be softer than the source." Outputs are re-decoded and dimension-verified before every download, enlarged or not.

What the resizer cannot know

The verification checks format and dimensions; it does not look at the picture. The tool cannot tell you whether a downscaled result is sharp enough for its destination, whether a stretched image looks wrong, or whether an enlargement is acceptable — it reports the arithmetic and the flags, and leaves judgement to you. It does not know the destination's rules either: the box in fit mode is yours to choose, and nothing on this page sets a file-size target.

Common misreadings

"Fit makes it 1200×1200." Fit makes it fit. The illustrative 4032×3024 photo comes out 1200×900; no padding is added to reach the box.
"25% is a quarter of the file." It is a quarter of each side — 6.25% of the pixels — and the byte count is measured, not predicted.
"Exact mode will tell me if it distorts." It will not; the plan carries an enlargement flag and nothing else. Tick the lock and type a width.
"The lock works from either field." On this page the lock derives height from width: a width of 1600 on the illustrative 4032×3024 photo yields 1200 high. Type the width.
"My GIF stays a GIF." It comes back as a PNG named sticker.png, first frame only if it was animated.
"A warning means it failed." A warning is a note; the download still appears. A refusal is the row's error with no download — the two wordings above are different.
"Resizing is how I hit an upload limit in kilobytes." Resizing changes the pixel count, but this page has no byte target. Resize here, then set the kilobytes on the Image Compressor.

Resizing changes the pixel count; compression changes how those pixels are encoded — chain into the Image Compressor for quality or target-KB control. To change format at the same original size, see PNG to JPG, WebP to PNG, or their siblings in the sidebar. Building a document from resized pages? Image to PDF. For the arithmetic behind every figure on this page, read Resizing math; the other guides cover detection, the pipeline, and what re-encoding strips.

Frequently asked questions

What is the difference between fit, exact, and percent?

Fit scales the image to sit WITHIN your box, preserving its aspect ratio — an illustrative 4032×3024 photo fit into 1200×1200 becomes 1200×900. Exact stretches to precisely the dimensions you type (with an optional aspect lock that derives height from width). Percent scales uniformly — 25% of the same photo is 1008×756.

Does resizing keep my file’s format?

Yes for PNG, JPG, and WebP — the output re-encodes in the same format you dropped. GIF and BMP inputs come back as PNG, because browsers can decode but not encode those formats; the row notes it when it happens. A HEIC file, which the picker does not list but the tool still reads, also comes back as PNG because the site never encodes HEIC; the row says so. AVIF is also accepted — the tool takes every format the engine decodes — but the resizer encodes only through the canvas as PNG, JPEG or WebP while expecting AVIF back, so the row ends in a verification error instead of a resized AVIF; convert it with the AVIF to PNG or AVIF to JPG converter first, then resize the result.

Can I make an image bigger?

Yes — allowed, but flagged. Upscaling cannot create detail that was never captured; the result is a smooth interpolation, visibly softer than a true high-resolution image. The tool warns on the file row rather than blocking you.

Is there a size limit?

Outputs are capped at 16,384 pixels per side and 80 megapixels overall — this engine's rule, not a property of images. Plans above 50 megapixels also carry a performance warning. Inputs are limited separately, as the methodology page states, to 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection, so a browser tab cannot be overwhelmed.

Does resizing reduce quality?

Downscaling resamples pixels — technically lossy, practically the point: fewer pixels is what you asked for. Lossy formats re-encode at the engine's default quality parameters — 0.92 for JPG and 0.85 for WebP on the canvas 0–1 scale — stated, not recommended. Each output is re-decoded and its exact dimensions verified before download.

Are images uploaded to be resized?

No. The resample happens on a canvas in your tab. No image data leaves your device — the methodology page shows how to confirm it.

What happens when the filename’s extension is wrong?

The resizer reads a file’s leading bytes and ignores what the name claims. An invented file named holiday.png whose bytes begin FF D8 FF is detected as JPEG; the row shows a notice that the name says PNG but the bytes are JPEG, the resize runs on the JPEG content, and the download is named holiday.jpg — the extension the file should have carried all along.

Does exact mode warn me if the proportions change?

No. Exact mode does what it says: an illustrative 4032×3024 photo asked for at 1200×1200 becomes 1200×1200, and the plan carries no distortion flag — its only flag is enlargement, which is not set here because neither dimension grew. To keep the shape, tick the aspect lock and type a width: 1600 wide derives 1200 high from the source’s own ratio.

Local processing: resampling runs on a canvas in your own browser tab — files are never transmitted. Verification steps live on the methodology page.

Resize images