How to Crop, Resize and Compress Images on the Filestack Free Plan

Dimensions decide image file size more than lossless compression does. We ran Filestack crop, resize, and compress requests against a free key on the same 319,136 byte photograph, so the results compare directly.

All three operations are on the free plan, so every URL in this article works on a free key.

Key takeaways

• Resize before compression because removing pixels produces the largest reduction in file size.
• Give resize one dimension to preserve aspect ratio, or use fit when both dimensions are fixed.
• Crop before resize when the coordinates refer to pixels in the original image.
• Use JPEG quality for a larger lossy reduction after choosing the final dimensions.
• Put tasks that remove pixels first and treat encoding as the last refinement.

The one thing worth knowing first

Most people reach for compress because of the name, and it is the weakest lever available. On that photograph it saved under seven percent. Resizing the same file to 400 pixels tall saved ninety percent.

Compression is not the weak part. The bytes are simply somewhere else. An image at 1024 by 1536 contains about fifteen times the pixel data of the same image at 267 by 400, and no amount of re-encoding recovers that difference. Decide the dimensions first and treat everything else as a refinement.

Resize

The resize task takes width, height, fit and align, and you can give it one dimension or both.

https://cdn.filestackcontent.com/resize=width:400/T5T2GRrxSjeNBbsIMaA8

 

Give one dimension and the other is calculated for you, preserving the aspect ratio. That is usually what you want, and it is why width:400 and height:400 return very different files from the same original. On this portrait photograph, height 400 gives you 267 by 400 and 33,311 bytes. Width 400 gives you 400 by 600, which is the larger image, and 69,512 bytes. Fix the dimension that matches the shape of the source, or you will enlarge the thing you meant to shrink.

Give both and fit decides what happens to the mismatch:

Request	Bytes
resize=height:400	33,311
resize=width:400	69,512
resize=width:400,height:400,fit:clip	33,311
resize=width:400,height:400,fit:max	33,311
resize=width:400,height:400,fit:crop	43,804
resize=width:400,height:400,fit:scale	47,408

clip and max both fit the image inside the box and leave the aspect ratio alone, which is why they match plain height:400 here. crop fills the box and discards the overflow, giving you a true square. scale distorts to fill, and is almost never what you want. The full set of options is in the image editing api guide.

Crop is what does the work in keeping a mixed gallery square when the originals are not.

Crop

Where resize scales the whole image, crop takes a rectangle out of it, in pixels, as dim:[x,y,width,height].

https://cdn.filestackcontent.com/crop=dim:[200,380,700,700]/resize=width:400/T5T2GRrxSjeNBbsIMaA8

 

Two practical notes. Percent-encode the square brackets as %5B and %5D when you send this from curl, because curl will not do it for you and a browser will. And crop before you resize, since the coordinates refer to the image as it is at that point in the chain. Crop first means you are working in the original’s coordinate space, which is the one you measured in.

Use resize with fit:crop when you want a square and do not care which part. Use crop when you know exactly which pixels you want.

Compress, and what it is actually for

https://cdn.filestackcontent.com/compress/T5T2GRrxSjeNBbsIMaA8

On its own this returned 297,412 bytes against the 319,136 byte original. Under seven percent, for a task whose name promises more.

The reason is that the source was already a JPEG, and JPEG is already compressed. compress is doing lossless work on a file that has little lossless redundancy left. Point it at a PNG screenshot and it earns its name. Point it at a photograph off a phone and it will not.

It is still worth chaining, because seven percent of an already small file is free. Resizing first and then compressing returned 64,765 bytes, against 69,512 for the resize alone.

Quality, the lever most people skip

If the goal is a smaller file and you can accept lossy re-encoding, quality does more than compress ever will.

Request	Bytes	Saving
output=format:jpg/quality=value:90	303,711	5%
output=format:jpg/quality=value:70	148,235	54%
resize=width:400/output=format:jpg/quality=value:70	25,803	92%

That last row is the chain to copy. Resize and quality together took a 319,136 byte photograph to 25,803 bytes, and at 400 pixels wide the difference between quality 70 and the original is not visible in a browser.

 

Note that quality only applies to JPEG, so it has to follow an output=format:jpg in the chain. Deciding whether to convert to webp instead is a separate call, and the format comparison covers it.

Order changes the answer

Tasks run left to right, and the order is not cosmetic.

Chain	Bytes
output=format:webp alone	322,232
resize=width:400 then output=format:webp	54,984
output=format:webp then resize=width:400	54,970
compress then resize=width:400	69,536
resize=width:400 then compress	64,765

Converting the full size image to WebP made it very slightly bigger, 322,232 bytes against 319,136, because the source was already a compressed JPEG. Resizing first and then converting gave 54,984, an eighty-three percent saving from the same two tasks. Reversing those two lands in the same place, so between them the order barely matters. Where it does matter is compression, where resizing first saves 4,771 bytes over compressing first. The rule that falls out of this is simple. Put the task that removes pixels first, and treat encoding as a refinement of a file you have already made small. Anything that runs before the resize is doing expensive work on data you are about to throw away.

Where the free plan stops

Every request demonstrated in this article runs on a free key, and facial detection does too. These three are a small part of it, and everything else a free key runs covers the rest. That means blur faces is available alongside the crop and resize work above.

Two neighbours of these operations run on the higher plans, and they are worth knowing by name because they solve the problem you will hit next. Smart cropping finds the subject and crops around it, so you stop choosing coordinates by hand. Upscaling adds detail rather than removing it, for the case where the source is smaller than the slot. Both are the same kind of work as the tasks above, done by a model instead of by arithmetic.

One thing to plan for on any plan: each distinct transformation URL counts against your allowance once, though results then cache for about thirty days, which is covered in the file delivery walkthrough. The free plan page has the numbers.

Where to go next

Build the chain once and template it. Because these are URLs rather than jobs, the version of your image you serve is a string your application assembles, which means changing every thumbnail on your site is a one line change and no reprocessing. What that costs once real traffic arrives is worked through in serving those sizes from a CDN. Once you are doing that across a real site rather than one image, the file delivery workflow guide covers how caching, formats and delivery fit together.

Start with resize=width:400/output=format:jpg/quality=value:70 on your own file and compare it to what you are serving now. On the 319,136 byte test photograph, that one chain removed 92 percent of the bytes.