Compress and resize an image in one step

You can, and often you should. The difference this page makes is to the picture, not the clock: each tool decodes and re-encodes, so going through two of them means two lossy generations rather than one, and JPEG and WebP both lose a little every time. This page builds one operation that crops, resizes, corrects and encodes in a single pass, so your image is only compressed once. It is not faster - measured on a 20 megapixel photograph it takes noticeably longer than the single-purpose tools, because working out how to meet a requirement means encoding the image several times to find the right quality, and that search runs on the page rather than in a background thread. Use the individual tools when you know exactly what you want and speed matters; use this one when you want the result to be right and only encoded once.

It means the job finished and produced a usable file, but one thing you asked for could not be fully met - most often a file size that would need quality low enough to look obviously damaged. Rather than grinding the quality down until the number is technically hit, the tool stops at a floor, gives you the closest result it did manage, and tells you exactly how close. The file is still there to download, because it is usually still useful. A tool that reported that as a plain success would be lying, and one that reported it as a failure would be throwing away your work.

Not unless you switch on background removal, which is clearly labelled and asks before it sends anything. Every other operation on this page - cropping, resizing, correcting, converting, compressing and the size search - runs inside your browser, and a content security policy the browser enforces stops this page sending your image to another domain. Before you process anything, the page lists every step in the job and says where each one runs, so a job that is partly remote never looks like one that is not.

From what you say it has to fit. A destination resolves to a set of published requirements - dimensions, a shape, sometimes a byte ceiling - and the solver works out the smallest set of changes that satisfies them: crop to the right shape only if the shape is wrong, resize only if it is too big, convert only if the format has to change. It never enlarges an image to reach a target unless you ask, because inventing pixels is not the same as having them, and it says so when the result is smaller than the requirement.

Not on this page yet. The bulk tools handle folders for compressing and resizing, and they run the same engine underneath. Background removal in particular is deliberately excluded from folders: it costs money per image and sends each one to an external service, so doing a hundred in one click would be an easy way to spend a lot and share a lot without noticing.

Yes, which is why the tool fixes it rather than letting you rearrange it. Background removal runs first so everything afterwards acts on the cut-out; the crop comes next because it decides which part of the image the rest of the job is about; corrections apply to the pixels that survive; and the encoding is last, because it is the step that commits to a format and a file size. Letting you put the resize before the crop would let you build a job that produces a worse result with nothing on screen explaining why.