Batch Resize Images in Automator Without Destroying the Originals

Yes. Every image action in Automator’s Photos category operates on the files you hand it, not on copies of them. This is stated in the action bundle itself. Read it yourself:

/usr/libexec/PlistBuddy -c "Print :AMWarning" \
  "/System/Library/Automator/Scale Images.action/Contents/Info.plist"

That prints:

“This action will change the image files passed into it. Would you like to add a Copy Finder Items action so that the copies are changed and your originals are preserved?”

The same plist names the remedy: Action: com.apple.Automator.CopyFiles, ApplyButton: Add, IgnoreButton: Don’t Add, Level: 2. Apple built the fix into the warning. It just does not apply it for you, and the dialog appears once, when you first drag the action in, not on every run.

Seven of the built-in image actions carry that warning. Two more change your files and say nothing at all:

Add Thumbnail Icon to Image Files is the sneaky one. It modifies the files you pass it and has no AMWarning key whatsoever. What it adds is a multi-megabyte com.apple.ResourceFork extended attribute that ls -l will not show you, which is documented in the sips reference under the -i flag. Do not put it in a batch.

Open Automator. Choose New Document, then Quick Action if you want it on the Finder right-click menu, or Application if you would rather drag a folder onto a droplet. Set the header to receive image files in Finder.

Then, in this order:

Drag Scale Images in after Copy Finder Items and click Add when the warning appears; Automator inserts the copy step for you and you can drag it to the top. Save with a name you will recognize in a context menu. Quick Actions land in ~/Library/Services/ and appear immediately, a path covered in detail in the Finder Quick Action walkthrough.

Two things about Copy Finder Items that only show up once you run it for real. It copies before anything is compressed, so a 324 MB selection means 324 MB of duplicates on disk first. And with Replacing existing files unchecked it uses Finder’s own collision naming, which we confirmed by running the same workflow on the same file three times:

one.jpg
one copy.jpg
one copy 2.jpg

Nothing was overwritten, which is the point, but three runs over a weekly folder leaves you a junk drawer. Empty the destination between runs or use a dated folder.

Verify it before you trust it. Put three throwaway copies in a folder, note the byte counts, run the workflow, and check the byte counts again. Ours:

JPEG quality 75, and you cannot change it. There is no quality control anywhere in the action — the entire parameter set is percentageValue, scaleValue, scaleMethod and sizeValue.

We know the number because the output is byte-identical to sips. The file Automator produced and the file from sips -Z 1200 base.jpg --out out.jpg share the same SHA-256, and so does sips -Z 1200 -s formatOptions 75:

If byte identity is not enough, feed Scale Images something that is not an image. The error Automator surfaces is:

The action “Scale Images” encountered an error: “Error: Cannot extract image from file.
Error 13: an unknown error occurred
Try 'sips --help' for help using this tool
”

Apple’s GUI image action is a wrapper around the command-line tool, and it leaks the tool’s own help text into the dialog. That is worth knowing for a practical reason: everything true of sips is true of Scale Images. Quality 75, no size guard, no WebP output, and metadata that survives everything. On our tagged fixture, the coordinates, the capture date and the camera model all came through a Scale Images pass unchanged. The full behavior map is in the sips command reference.

One more parameter trap in the same family. Change Type of Images defaults to imageType = TIFF. Convert that 194,972-byte JPEG to TIFF and you get 2,282,336 bytes, 11.7× larger. If you drop that action into a resize workflow without opening its popup, you have built a file-inflater.

Faster than its reputation, and faster than a plain sips loop even though it copies every file first. One hundred copies of the 3.4 MB fixture, all resized to a 1,200 px long edge, same machine, same afternoon:

Read that honestly in both directions. Automator beat a single-threaded sips loop by 1.8× while also duplicating 324 MB of source files, which means Scale Images is doing work concurrently. Eight parallel sips processes beat everything on the clock and cost nothing. And at identical pixel dimensions and the same nominal quality of 75, Smol’s encoder returned files 44.8% smaller than the one Apple ships, at 8.5 times the wall clock of the Automator route.

Which of those matters depends entirely on where the files are going. For a folder of reference shots on your own disk, the fast free route wins and we would rather you used it. On a page that loads the whole set, the 87 KB-per-image gap is 8.7 MB every time somebody visits.

Scale Images upscales. This is the failure that pairs worst with the destructive default. To Size is a target, not a ceiling. We took a 600 × 316 file of 54,031 bytes, ran the 1,200 px workflow over it, and got back a 1,200 × 632 file of 130,746 bytes: 142% larger, blurrier, and written over the original. A folder of mixed sizes run through a single Scale Images pass will quietly inflate everything below your target. There is no “only if larger” checkbox. Sort your input or split the batch.

It does not go into folders. Hand Automator a folder rather than files and Copy Finder Items duplicates the folder, then Scale Images reports “The action ‘Scale Images’ was not supplied with the required data.” and stops. The image actions accept public.image, not directories. Add a Get Folder Contents action, with Repeat for each subfolder found if you need recursion.

One bad file does not stop the batch, but it does hide in the output. We put a 13-byte text file named aaa-broken.jpg first in a four-file run. Scale Images raised the error above, processed the other three correctly — and Copy Finder Items had already copied the broken file into the destination. Your output folder now contains a file that was never resized and looks exactly like one that was. Nothing tells you which.

PNGs stay PNGs. A 1,600 px PNG came out as a 1,200 px PNG, 1,813,827 → 1,074,346 bytes. Correct behavior, and worth knowing if you expected a resize to also give you a smaller format. It will not. For that you want a real format conversion.

Nothing checks whether the result got smaller. Automator has no size guard, the same gap the Quick Action article solves with four lines of shell. Point this at a folder of already-optimized web assets and you will spend an afternoon making them worse.

automator(1) runs a saved workflow, which is how every number above was taken. The synopsis is automator [-v] [-i input] [-D name=value ...] workflow, and the trap is that only the first -i is honored. We passed three and exactly one file was processed.

The documented escape is buried in one sentence of the man page: if input is -, standard input is used and each newline-terminated line becomes one input item. That turns the workflow into something you can drive from a pipeline:

# Wrong — only shot-1.jpg is processed
automator -i shot-1.jpg -i shot-2.jpg -i shot-3.jpg Resize.workflow

# Right — every path on stdin becomes an input item
printf '%s\n' /path/to/shots/*.jpg | automator -i - Resize.workflow

That second form is what produced the 7.9-second figure on 100 files. It also gives you back the thing Automator’s GUI takes away: find, so you can filter by size or modification date before anything is copied.

# Only images above 1 MB, modified in the last week, into a dated folder
DEST="$HOME/Resized/$(date +%Y-%m-%d)"
mkdir -p "$DEST"

find "$SRC" -type f \( -iname '*.jpg' -o -iname '*.png' \) \
     -size +1M -mtime -7 -print |
  automator -i - "$HOME/Library/Services/Resize 1200.workflow"

Both of those were run before publication. If you are already comfortable at this level, be honest with yourself about whether the Automator step is earning anything over sips -Z 1200 behind xargs -P 8, which finished the same job in 2.3 seconds with no workflow bundle to maintain.

Use Automator. It is free, it is installed, it survives OS upgrades, it puts a resize on the right-click menu without a single line of code, and on our test it was almost twice as fast as the obvious shell equivalent. If you need a folder of screenshots at 1,200 px before you paste them into a ticket, build the two-action workflow and stop reading. We would rather you did that than paid us.

Use the shell. If you are the kind of person who already reaches for find, sips -Z under xargs -P 8 is faster than every GUI route here, gives you a size guard in one stat -f%z comparison, and produces byte-identical output to Automator because it is the same encoder. The whole flag surface is in the sips reference, and the wrapping-it-in-a-menu-item version is in the Finder Quick Action walkthrough.

Reach for something else when:

The folder has mixed sizes. Scale Images will upscale everything below your target and overwrite it. Guarding that in Automator means a second workflow and a filter; guarding it in shell means one sips -g pixelWidth test.

You need WebP or AVIF. Neither sips nor Scale Images can write WebP. AVIF is writable from sips but not exposed anywhere in Automator.

You need to know what happened. A 400-file Automator run reports a spinning gear and nothing else. Which three files refused to shrink is not a question the workflow can answer.

The bytes are going on a CDN. At identical dimensions and the same nominal quality, Smol’s output was 44.8% smaller than Apple’s encoder, along with a size guard that returns your original when compression would make a file worse, per-file results, and an output policy that cannot overwrite an input. It is $29 once. For a folder of holiday photos, Automator is genuinely enough.

To skip the right-click entirely, a folder that resizes on drop is the better ergonomic, and the Folder Action version of this article covers the re-trigger loop that breaks most tutorials. The PDF equivalent, including the identical Copy Finder Items warning on the Quartz filter action, is in batch compressing PDFs on a Mac. And if these images are destined for a repository, resize them before the commit, because git keeps the 3.4 MB version forever.

One more route worth a line, because it removes the part of this job people actually hate. Smol exposes its whole surface over an MCP server, so an AI coding agent can pick the files, predict the output paths before anything is written, run the batch and hand back a per-file table. The Smol row in the timing table above was produced exactly that way.