Image Resizer / Cropper

How to use it

1. Drop an image on the stage, pick one with the button, or paste a copied screenshot straight from the clipboard — PNG, JPEG, WebP, GIF, AVIF and SVG all decode here.
2. Choose a mode: Exact size stretches to the width and height you type, Fit within scales to sit inside the box, Fill covers the box and center-crops the overflow, Percent scales both sides at once.
3. Or skip the arithmetic: pick a preset — every row carries its platform's documented dimensions — and the width and height fields fill themselves.
4. Turn on Crop to trim first: drag the rectangle or its corner handles, type coordinates into the crop fields, or nudge with the arrow keys — 1 px per press, 10 with Shift.
5. Check the live output line, press Resize image (or ⌘/Ctrl + Enter), then Download image — the filename carries the real output size.

Load a photo or graphic, then resize, crop, rotate or flip it to exact pixels, a percentage, or one of twelve cited social-media presets, and export PNG, JPEG or WebP. Every pixel is processed by this browser on this device — keep the DevTools Network panel open while you edit and the request log stays empty from drop to download. Sources up to 20 MB and 10,000 px per side are accepted.

How it works

The whole tool is a plan-then-draw pipeline. Your settings never touch pixels directly: they compile into an ordered list of canvas steps — crop, then rotate, then flip, then one or more scaling draws — with every dimension resolved by integer math up front (fractions go through Math.round, never truncation, so 50 percent of 1,599 px is 800, not 799). The page shows you the resolved output size before anything renders, and the same plan replays identically in a background worker or on the main thread.

Phone cameras usually store rotation as metadata instead of rotating pixels, so a naive canvas draw shows portraits lying sideways. Decoding here requests imageOrientation: "from-image", which makes the browser apply the stored orientation before the first draw — the dimensions you see are the upright ones, and every crop coordinate refers to the image as you actually view it.

Shrinking far in a single draw looks bad for a measurable reason: bilinear resampling reads a small neighborhood around each output pixel, so past a 2× reduction whole source pixels fall between the samples and fine detail aliases into noise. When a plan shrinks to half or less on both axes, the scale step decomposes into iterative halvings — 4,032 px falls to 2,016, then 1,008, then the exact target — so every pass stays inside the filter's window; an exact-size stretch that squeezes only one axis draws in a single pass instead. The output line counts these passes for you.

A canvas export is a brand-new file encoded from raw pixels, and that cuts both ways. Nothing of the original container survives — EXIF orientation, GPS position, camera model, color-profile tags — because the encoder never sees the original bytes, only the drawn bitmap. If the location stamp in a photo worried you, the export is clean of it; if you needed the capture data, read it out of the original before resizing. The warning under the plan states this on every run rather than only when it surprises you.

Examples

1600×1200 photo → exact 800×600

scale 800×600
= 800×600 px

4032×3024 camera photo → fit the OG preset

scale 2016×1512
scale 1008×756
scale 840×630
= 840×630 px

3000×2000 → rotate 90° and scale to 50%

rotate 90°
scale 1000×1500
= 1000×1500 px

1920×1080 frame → crop, then fill a 400×400 avatar

crop 600×600 at (550, 100)
scale 400×400
= 400×400 px

Every example on this page is executed against the same engine that powers the tool, on every build.

Common errors

The crop rectangle leaves the image: 600×600 at (600, 300) does not fit inside 1000×800 px.

Crop coordinates are source-space pixels, so x plus width must stay inside the real image — here 600 + 600 needs 1,200 px of a 1,000 px frame. On the page every edit clamps to the frame — drags, nudges and typed coordinates alike — so this refusal is the engine's own backstop: each plan re-checks the rectangle against the image's true upright dimensions before anything draws.

The output must be between 1 and 10,000 px per side — this plan resolves to 12,000×630 px.

The cap applies to the RESOLVED output, which is why the message names both figures. A percentage can trip it too: 300 percent of a 4,000 px side is 12,000. Halve the target or scale in two sessions if you genuinely need something that large.

This file is larger than the 20 MB limit for this tool. For big photos use the CLI: sips -Z 800 photo.jpg --out photo-800.jpg

The byte gate runs before any decode starts — files that heavy are nearly always photographs carrying more pixels than any web target uses. The printed macOS line resizes locally with the same aspect-preserving behavior; on Linux, ImageMagick's convert -resize does the equivalent.

Keyboard shortcuts

⌘/Ctrl + Enter

Resize with the current options — the plan line shows what you will get first.

⌘/Ctrl + S

Download the resized image. On this page the shortcut saves your output, not the page itself.

Arrow keys

Move the crop rectangle 1 px while it or a corner handle has focus; on a handle they resize instead.

Shift + Arrow keys

The same crop moves and resizes at 10 px per press.

t

Cycle the color theme (ignored while typing in a field).

? or ⌘/Ctrl + /

Open the keyboard shortcut overlay.

Esc

Close the topmost dialog — the loaded image and options stay put.