DEV Community

Cover image for Batch Image Processing: From Photoshop Actions to Browser Pipelines — What Actually Works
Maxim Mitenkov
Maxim Mitenkov

Posted on

Batch Image Processing: From Photoshop Actions to Browser Pipelines — What Actually Works

I process between 50 and 100 images every month. Portfolio shots, Behance uploads, Pinterest pins, client deliverables in multiple formats. For years I jumped between three bad options: Photoshop actions that break when the canvas size changes, ImageMagick scripts I wrote once and forgot how to edit, and cloud converters that make me upload client artwork to someone else's server.

Last month I got tired enough to build something better. But before I tell you what I made, let's look at what already exists — and where each approach falls apart.


The Landscape: 5 Ways to Batch-Process Images

Approach Setup Time Privacy Flexibility Learning Curve Best For
Photoshop Actions Minutes ✅ Local Low Low Repetitive, identical workflows
ImageMagick / CLI scripts Hours ✅ Local High High Developers, server pipelines
Cloud converters (TinyPNG, Squoosh) None ❌ Upload required Low None One-off optimization
Cloud APIs (Sharp, Cloudinary) Medium ❌ Upload required High Medium Production apps, automation
Browser-based pipeline None ✅ Local Medium Low Designers, freelancers, privacy-first workflows

1. Photoshop Actions

The good: If every image is the same size and needs the same sequence (resize → sharpen → export JPEG at 80%), Actions are fast. Record once, play on a folder.

The bad: Actions are brittle. Change the aspect ratio of your source images and the crop breaks. Need a slightly different export for one client? Duplicate the entire action set. Need to process 200 images while you grab coffee? Photoshop will hang or crash.

When to use it: You are a photographer with a fixed studio workflow and identical source files.

When to skip it: Variable dimensions, multiple output formats, or anything that needs logic (e.g., "if width > 1920, resize; else, keep original").


2. ImageMagick & CLI Scripts

The good: Infinite flexibility. Resize, crop, composite, watermark, convert formats — all in one command. Runs on servers. Free. Fast.

The bad: You are now a programmer. The syntax is arcane (convert input.jpg -resize 800x800^ -gravity center -extent 800x800 output.jpg). Scripts you write in January become unreadable by June. And if you need visual feedback — "does this crop look right?" — you're opening every output file manually.

When to use it: You are a developer building a CI/CD pipeline, or you need to process thousands of images on a server.

When to skip it: You are a designer who wants to see what happens before you commit to a workflow. Or you need to tweak parameters visually.


3. Cloud Converters (TinyPNG, Squoosh, etc.)

The good: Zero setup. Drag, drop, download. Squoosh even runs in the browser (though it's single-image, not batch).

The bad: You upload your files to a third party. For client work, NDAs, or personal artwork, that's a dealbreaker. And batch features are usually premium, subscription-only, or nonexistent.

When to use it: Quick one-off optimization of a few personal images where privacy doesn't matter.

When to skip it: Client files, proprietary artwork, or anything requiring a repeatable workflow.


4. Cloud APIs (Sharp, Cloudinary, Uploadcare)

The good: Production-grade. URL-based transformations (?w=800&q=80). Integrates into apps. Handles millions of images.

The bad: Requires backend integration. Costs scale with usage. And again — your images leave your device.

When to use it: You are building a SaaS or e-commerce platform that serves dynamic images.

When to skip it: You are a freelancer processing files for a one-time deliverable. Overkill and expensive.


5. Browser-Based Pipelines (What I Built)

I wanted something that combined the privacy of ImageMagick, the visual feedback of Photoshop, and the zero-setup of cloud tools — without the downsides of any of them.

Image Pipeline runs entirely in the browser. You build a visual pipeline by connecting nodes:

[Load Images] → [Resize to 800px width] → [Compress 80%] → [Export WebP]

Hit Process. Everything happens via Canvas API in your tab. Images never touch a server. Download a ZIP.

The good:

  • Zero setup — open URL, drag files, done
  • Privacy — no upload, no account, no API key
  • Visual — see the pipeline, tweak parameters, preview results
  • Repeatable — save the pipeline, reuse next week
  • Free tier — 10 files/day, no credit card

The bad:

  • Browser memory limits (don't throw 500 RAW files at it)
  • No server-side automation (it's a GUI tool, not a CI/CD step)
  • Simpler than ImageMagick for advanced compositing

When to use it:

  • You are a designer, illustrator, or photographer batch-preparing assets
  • You handle client files under NDA
  • You want a repeatable workflow without writing code
  • You need multiple output formats from one source set

When to skip it:

  • You need to process 10,000 images programmatically (use ImageMagick)
  • You need dynamic image serving in a web app (use Cloudinary)
  • You need advanced layer compositing (use Photoshop)

The Decision Matrix

"I need to resize 50 portfolio images for my website"
→ Browser pipeline wins. 2 minutes, no upload, ZIP download.

"I need to optimize 10,000 user-uploaded avatars per day"
→ Cloud API or ImageMagick. This is a backend problem.

"I need to compress one image for Twitter"
→ Squoosh or TinyPNG. Fastest for single files.

"I need to apply the exact same crop and color grade to 200 studio photos"
→ Photoshop Actions. If the workflow never changes, Actions are still king.

"I need a script that resizes, watermarks, and uploads to S3 automatically"
→ ImageMagick + Bash/Python. You're a developer; this is your world.


How It Works Under the Hood

If you're curious about the technical side:

  • Image decoding — native FileReader + Image constructor
  • Manipulation — HTML5 Canvas API (drawImage, toBlob)
  • Compression — Canvas toBlob with quality parameter
  • ZIP generation — JSZip, entirely client-side
  • No WebAssembly — intentionally kept simple to avoid bundle bloat

The entire app is static HTML/JS hosted on Vercel. No server, no database, no API routes for image processing.


Try It or Build Your Own

If you process images regularly and none of the existing tools fit your workflow cleanly, give it a shot:

👉 imagepipeline.art

Or if you're a developer and prefer CLI — honestly, stick with ImageMagick. It's unbeatable for automation. This tool is for everyone else who got tired of the trade-offs.


What's your batch processing workflow? Do you script it, automate it, or still click through Photoshop one file at a time?

Top comments (0)