Photoshop Batch Processing: Image Processor, Droplets & Scripts at Scale

By Michael Peters · Published May 8, 2026 · Last updated May 8, 2026 · 9 min read

← Back to Blog

The five batch primitives

Photoshop’s batch story is unusual. Most Adobe applications give you ExtendScript and Actions; Photoshop gives you those plus three more options — the Image Processor, Droplets, and the Photoshop API — each suited to a different scale and audience. Recognising which fits your job is most of the production decision.

1. Image Processor — the GUI bulk converter

Found at File → Scripts → Image Processor. A built-in dialog that handles 80% of bulk Photoshop work without writing a line of code: take a folder of images, convert to JPEG, PSD, or TIFF, optionally resize, optionally run an Action, save to a destination folder. Right for designers and production staff who don’t script.

Limitations: only the three formats above (no PNG, no WebP without a custom Action), one fixed resize per run (no per-file rules), Actions in the optional pre-processing slot rather than between operations. For everything inside those limits, it’s the simplest production batch tool Photoshop offers.

2. Batch command — Action-driven batching

Found at File → Automate → Batch. Runs a recorded Action against every file in a source folder, with output naming rules, optional override of Open/Save commands, and per-file error handling. The classic production tool for "do this Action to every file in this folder", with more output flexibility than the Image Processor.

Pairs naturally with Actions and Droplets — covered in Photoshop Actions and Droplets. The Batch command is what Droplets ultimately invoke under the hood.

3. ExtendScript folder loops — for conditional logic

The production answer when neither the Image Processor nor the Batch command can express what you need:

• Conditional logic ("if the image has an alpha channel, do X; otherwise Y")
• Multi-format export from a single source (one PSD → press JPEG, web JPEG, retina PNG, transparent PNG)
• External data (CSV-driven naming, watermarks per row, conditional filenames)
• Operations that aren’t recordable as Actions (some Smart Object operations, certain History API calls)
• Manifest-driven runs where each input file has its own configuration

(function () {
  var srcFolder = Folder.selectDialog('Source folder');
  if (!srcFolder) return;
  var dstFolder = Folder.selectDialog('Destination folder');
  if (!dstFolder) return;

  app.displayDialogs = DialogModes.NO;

  var files = srcFolder.getFiles(function (f) {
    return /\.(jpg|jpeg|png|tif|tiff|psd)$/i.test(f.name);
  });

  var ok = 0, errs = [];
  for (var i = 0; i < files.length; i++) {
    try {
      var doc = app.open(files[i]);
      processFile(doc, dstFolder);
      doc.close(SaveOptions.DONOTSAVECHANGES);
      ok++;
    } catch (e) {
      errs.push(files[i].name + ': ' + (e.message || e));
      while (app.documents.length > 0) {
        app.documents[0].close(SaveOptions.DONOTSAVECHANGES);
      }
    }
  }
  writeLog(dstFolder, ok, errs);
}());

That skeleton is the basis of most production Photoshop batch scripts. Everything else is filling in processFile.

4. UXP plugins with batch UI

When batch jobs need configuration frequently — choose Action presets, pick manifests, configure naming conventions — a UXP plugin with a batch panel is the right answer. The plugin provides the UI; the actual batch processing runs as the panel iterates over files. Useful when batch jobs are run by users (not developers) and configuration discoverability matters. Covered in UXP vs CEP for Photoshop and Photoshop extension technologies.

5. Photoshop API — cloud-scale headless

For genuinely high-volume work that exceeds what desktop Photoshop can reasonably handle — thousands of images per hour, web-driven processing, e-commerce image pipelines — the Photoshop API is the right tool. A managed Adobe-hosted REST service that accepts a PSD or image, applies operations server-side, and returns the result. Covered in Photoshop API for cloud-scale image processing.

Naming conventions that survive a re-run

The single most important production decision in any batch job is the output naming convention. Three rules:

1. Output is reproducible from input. Output filename should be derivable from the input filename and the export type alone. logo-acme.psd → logo-acme.jpg, logo-acme@2x.png is good; output-1842.jpg is bad — you can’t tell what generated it, and re-running produces different filenames.
2. Re-running is idempotent. If the script already produced logo-acme.jpg, re-running should overwrite the same file, not produce logo-acme-2.jpg.
3. Output goes to a sibling folder. Mixing input and output in the same folder makes the next batch pick up its own outputs as inputs — predictably bad results.

The pattern: <source-name-without-ext>-<variant>.<ext>, where variant is one of web, print, 1x, 2x, thumb — a short, stable token.

Multi-format export from a single source

The classic Photoshop e-commerce case: a folder of working PSDs needs to produce, per file, a high-quality JPEG for press, a web-optimised JPEG, a 1x PNG, a 2x PNG, and a thumbnail. Doing each as a separate Image Processor run drifts state between runs (unless source files are saved between operations). Doing all five in one ExtendScript pass is reliable:

function processFile(doc, dst) {
  var base = doc.name.replace(/\.(psd|tif|tiff)$/i, '');

  // Press-quality JPEG (max quality, original size)
  var jpgPress = new JPEGSaveOptions();
  jpgPress.quality = 12;
  doc.saveAs(new File(dst.fsName + '/' + base + '-press.jpg'),
    jpgPress, true, Extension.LOWERCASE);

  // Resize for web variants (work on a duplicate so original size persists)
  var webDoc = doc.duplicate();
  webDoc.resizeImage(UnitValue(1200, 'px'), null, 72, ResampleMethod.BICUBIC);

  // Web JPEG (quality 8 ~ "High")
  var jpgWeb = new JPEGSaveOptions();
  jpgWeb.quality = 8;
  webDoc.saveAs(new File(dst.fsName + '/' + base + '-web.jpg'),
    jpgWeb, true, Extension.LOWERCASE);

  // 1x PNG and 2x PNG (export to PNG via a Save for Web call)
  webDoc.exportDocument(new File(dst.fsName + '/' + base + '.png'),
    ExportType.SAVEFORWEB, pngExportOptions(false));

  // Close the duplicate
  webDoc.close(SaveOptions.DONOTSAVECHANGES);
}

One open of the source per file. Multiple outputs per file. The doc.duplicate() pattern is important — resizing the working duplicate keeps the original document untouched, so subsequent operations (other size variants, archive PSD) still see the original dimensions. The print/web parameter differences for image output are covered in Print PDF vs Web PDF (the principles transfer to JPEG/PNG output too).

Error handling that doesn’t halt the batch

The single biggest source of pain in production Photoshop batches is unhandled errors. A 200-image batch that aborts on file 73 because of a colour profile warning leaves you with 73 outputs and 127 unprocessed inputs — and no clear log of which succeeded.

app.displayDialogs = DialogModes.NO;

var ok = 0, errs = [];
for (var i = 0; i < files.length; i++) {
  try {
    var doc = app.open(files[i]);
    processFile(doc, dstFolder);
    doc.close(SaveOptions.DONOTSAVECHANGES);
    ok++;
  } catch (e) {
    errs.push(files[i].name + ': ' + (e.message || e));
    while (app.documents.length > 0) {
      app.documents[0].close(SaveOptions.DONOTSAVECHANGES);
    }
  }
}

var logFile = new File(dstFolder.fsName + '/batch-log.txt');
logFile.open('w');
logFile.writeln('Batch run: ' + new Date().toString());
logFile.writeln('Processed OK: ' + ok);
logFile.writeln('Errors: ' + errs.length);
for (var j = 0; j < errs.length; j++) logFile.writeln(' - ' + errs[j]);
logFile.close();

Two non-obvious details. DialogModes.NO suppresses Photoshop’s warning dialogs (missing fonts, ICC mismatches, modified files) so the batch doesn’t halt. The catch clause closes any document left open when the error fired — otherwise a script that fails partway through accumulates open documents and exhausts memory.

Common batch patterns

E-commerce product photography

The signature Photoshop batch use case. A folder of raw product shots needs background removal, colour correction, resizing to multiple variants, watermarking, and renaming per a SKU manifest. The combination of Smart Object replacement, Action playback, and ExtendScript orchestration handles thousands of products per day in production environments.

Format conversion

Convert a folder of TIFFs to JPEG; convert PSDs to PNGs with transparency; convert RAW to TIFF via Camera Raw. The Image Processor handles the simplest cases; ExtendScript handles cases needing conditional logic (different conversion based on image content).

Retouching at scale

Apply a consistent retouching Action (skin smoothing, colour correction, sharpening) to every image in a shoot. Recordable as an Action, run via the Batch command. The simplest production case.

Watermarking

Apply a watermark layer to every image in a folder, with the watermark size scaled to the image dimensions. Possible as an Action with conditional steps, easier as an ExtendScript. Variable text watermarks (per-row from a CSV) need ExtendScript.

Metadata operations

Strip EXIF, set IPTC fields, write XMP from external data. Photoshop’s metadata API is fully scriptable. Common production case for stock libraries and DAM ingestion pipelines.

Smart Object replacement at scale

One template PSD with Smart Objects representing variable artwork, a CSV of variants, an ExtendScript that replaces Smart Object contents and exports per-variant JPEGs. The Photoshop equivalent of variable data printing — covered for InDesign in InDesign Data Merge; the Photoshop pattern is similar but driven through Smart Object placement rather than data binding.

Running batches unattended

Most production batches run when a human is around. A few need to run overnight. Three things to know:

1. Photoshop must be running. ExtendScript executes in the host application; there’s no headless desktop Photoshop. Schedule the OS task to launch Photoshop with a startup script and let it close itself when done. (For genuinely unattended high-volume work, the Photoshop API replaces this entirely.)
2. No modal dialogs. app.displayDialogs = DialogModes.NO at the top. Avoid alert() entirely.
3. Use the log file. Unattended runs need a log because there’s no human watching the progress bar.

The escalation to the Photoshop API

The signs that desktop batch is the wrong tool:

• Volume thousands of images per hour, sustained
• Workflow driven from a web request queue rather than a desktop file picker
• Multiple parallel batch jobs need to run simultaneously across servers
• Production system needs no Photoshop instances on workstations — just an HTTP endpoint

The Photoshop API is purpose-built for these cases. The trade-off is per-call pricing versus desktop’s flat licensing — covered in the API post.

The honest take

Photoshop’s embarrassment of batch options is mostly a feature, not a bug: each tool fits a real production scale. Designers reach for the Image Processor for daily format conversion. Production teams use Droplets for hand-off and Batch for daily Action runs. Developers write ExtendScript for cases needing logic. UXP panels wrap configuration-heavy batches. The Photoshop API handles cloud-scale.

The mistake is reaching for the wrong tier. ExtendScript for what an Action would do is wasted effort; the Photoshop API for a designer’s daily folder of forty product shots is wasted budget. The decision is mostly about volume and audience — once you know those two, the right tool is usually obvious.