GetWebP CLI Dry Runs: Review Before You Write Files

Image conversion is safer when the first command does not write files. A dry run lets you preview what a converter would do before it creates WebP outputs, walks a folder recursively, or consumes time on a large batch. For teams handling client assets, product catalogs, or documentation images, that preview step can prevent avoidable cleanup.

GetWebP CLI supports --dry-run, which reports eligible files without converting them. Used well, it becomes a simple review gate between "I think this folder is ready" and "we are generating outputs." A useful dry-run workflow should be specific about what the preview proves and what it does not prove; otherwise it sounds safe while missing real release mistakes.

Use Dry Run on Unfamiliar Folders#

Run a dry run whenever the input folder is new, messy, or shared by multiple people:

getwebp ./images --dry-run

The point is to see what the tool would process. If the count is much higher than expected, stop and inspect the folder. You may have drafts, nested exports, old thumbnails, or files that do not belong in the migration.

A dry run is especially useful before recursive conversion because nested folders can hide outdated or duplicate assets. If you intend to process subdirectories, include the same recursive flag in the preview:

getwebp ./images --recursive --dry-run

Check Whether the Folder Is Too Broad#

One common mistake is converting from a parent folder that contains more than approved web images. For example:

campaign/
  originals/
  design-drafts/
  social-exports/
  optimized/

If you run conversion against campaign/, you may process files that were never meant for the website. A dry run can reveal that before output files are created.

Prefer a narrow input path:

getwebp ./campaign/originals --recursive --dry-run

Then convert only after the preview matches the intended source set.

Pair Dry Run With a Separate Output Folder#

Dry run reduces surprise, but output separation still matters. After the preview looks right, write outputs to a dedicated folder:

getwebp ./campaign/originals \
  --recursive \
  -o ./campaign/optimized \
  --quality 82

This keeps source files untouched and makes review easier. The dry run answers "what would be processed?" The output folder answers "where will generated files go?"

Do not skip the output folder just because the dry run looked clean. Clear separation is still useful for rollback and review.

Do Not Overread skip-existing in Dry Run#

Dry run is helpful when you change command options. Before a large conversion, confirm that your command points to the intended path and includes the intended traversal flags:

getwebp ./product-images --recursive --dry-run

Keep the boundary clear: dry run previews the candidate input set. It does not create output files, does not measure savings, does not prove visual quality, and should not be used as the only evidence that --skip-existing will skip the exact files you expect.

--skip-existing is useful when repeating a conversion and you do not want to regenerate files that already exist, but its check is based on whether the computed output path already exists. It does not prove the existing output is fresh, was made with the current quality setting, or came from the current source file.

For a repeat run, do the path preview first, then capture a real structured conversion report:

getwebp ./product-images \
  --recursive \
  -o ./product-images-webp \
  --quality 82 \
  --skip-existing \
  --json > ./reports/product-images.ndjson

Then inspect statuses and output paths:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, (.outputPath // ""), (.reason // ""), (.error // "")]
  | @tsv
' ./reports/product-images.ndjson

The review is not about distrust of the tool. It is about catching human path mistakes before they create output noise.

Know What JSON Mode Shows#

When you run a real conversion with --json, GetWebP emits newline-delimited JSON. The convert.completed event contains successCount, failedCount, and per-file results[]; Free plan truncation appears as convert.truncated. That data is appropriate for CI gates and release notes.

Dry run is different. Because it intentionally writes nothing, do not design automation that expects normal results[] savings data from a dry run. Use dry run for path review, then use a real conversion report for conversion outcomes.

Dry Run Does Not Replace Visual QA#

A dry run does not tell you whether the WebP output will look good. It only previews the processing set. You still need to convert a sample, compare source and output, and review the result in the page where users will see it.

For high-risk assets, keep the full workflow:

1. dry run the folder
2. convert a small sample
3. review visual quality
4. convert the approved set
5. inspect live pages after upload

Skipping visual review because the dry run passed would miss the most important quality question.

Record the Approved Command#

When the dry run and sample review pass, save the final command in a note or script. Include the input folder, output folder, format, quality setting, and any repeat-run flags.

Example:

Approved command:
getwebp ./originals --recursive -o ./optimized --quality 82 --skip-existing

Dry run checked:
2025-10-10

This lets another teammate repeat the workflow without reconstructing options from memory.

Use Dry Run in Handoff Reviews#

Dry run output can also support handoff. A designer can prepare the folder, a developer can run the preview, and both can agree that the input set is correct before conversion begins. If the handoff involves nested folders, save whether --recursive was part of the reviewed command.

For CI or release work, the same habit helps catch path mistakes early. A preview step is cheaper than discovering after deployment that the command processed a draft folder or skipped a required asset directory.

Use References for Format Decisions#

Dry run is a workflow control, not a format guide. GetWebP's CLI command reference documents --dry-run, --recursive, --output, and --skip-existing, and the JSON output guide documents convert.completed, convert.truncated, and per-file result fields. For technical background on WebP itself, Google's WebP documentation explains the format and encoder family. MDN's image file type guide gives context for choosing among common web formats.

The practical rule is simple: preview before writing, write outputs separately, and review quality before publishing. Dry runs keep the first step reversible, which makes the rest of the image conversion workflow easier to trust.