A No-Upload Image Compression Workflow for Client Work

Client images often contain more risk than they appear to. A folder of website assets may include unreleased products, staff photos, internal screenshots, event photos, customer logos, floor plans, or campaign material that has not been announced. Uploading those files to a random compression website may be convenient, but it also creates another data transfer the client did not necessarily approve.

A no-upload workflow keeps image compression on the machine where the files already live. It does not remove every security obligation, but it reduces unnecessary exposure and makes the process easier to explain to clients, designers, and legal reviewers.

"No upload" is only useful when the workflow defines the boundary. A client-safe workflow needs to state which files are processed locally, which files are excluded, whether the tool sends image bytes anywhere, what network checks may still happen, and what report proves the approved outputs came from the reviewed intake folder.

Start With a Client-Safe Intake Folder#

Do not optimize directly from a messy downloads folder. Create a project-specific intake folder and copy only the images that are approved for web preparation.

Use a structure like this:

client-site-images/
  originals/
  working/
  optimized/
  rejected/

The originals folder should remain unchanged. The working folder can contain resized copies. The optimized folder holds approved WebP, AVIF, JPEG, or PNG outputs. The rejected folder is useful when a setting produces visible artifacts and you want to keep an example for review.

This structure is simple, but it prevents accidental overwrites and makes handoff cleaner.

Remove Files That Should Not Be Processed#

Before compression, scan the folder for files that should not enter the web pipeline:

• raw camera files
• internal screenshots
• private documents exported as images
• client IDs or invoices
• design drafts with comments
• duplicate exports
• images that are not actually used on the website

Compression tools should not become a substitute for content governance. If a file should not be published, making it smaller does not make it safer.

Resize Before You Convert#

Many client images come from phones, cameras, or design exports that are far larger than the website needs. Resizing first usually gives a clearer win than changing the file format alone.

For each image, decide its largest real display size. A team photo used at 800 pixels wide does not need a 5000-pixel source in the published folder. Keep the high-resolution original, but generate a web-sized working copy before compression.

Then convert from that working copy:

mkdir -p ./client-site-images/reports

getwebp ./client-site-images/working \
  --recursive \
  --output ./client-site-images/optimized \
  --dry-run

getwebp ./client-site-images/working \
  --recursive \
  --output ./client-site-images/optimized \
  --quality 82 \
  --json > ./client-site-images/reports/conversion.ndjson

The dry run lets the team check the input set before files are written. The real conversion report gives reviewers a clear list of generated outputs without touching the source assets.

Summarize the report for the client record:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, .outputPath, .originalSize, .newSize, .savedRatio, .quality, .qualityMode, (.error // "")]
  | @tsv
' ./client-site-images/reports/conversion.ndjson

Also check for truncation or batch failure before handoff:

jq -r 'select(.type=="convert.truncated" or .type=="convert.failed") | .data' ./client-site-images/reports/conversion.ndjson

Review Quality in the Real Page#

Client review should not happen only in a file viewer. Place the optimized images into the actual page or a local preview. Check the areas clients notice first:

• faces
• product texture
• brand colors
• logo edges
• small text in screenshots
• shadows and gradients
• transparent edges

If a photo is emotionally important to the client, be conservative. The goal is a faster page, not a smaller file at the expense of trust.

Keep a Short Processing Record#

For each batch, keep a small note file:

Date: 2025-08-29
Source folder: originals/
Working size: max 1600px wide
Output format: WebP
Quality: 82
Report: reports/conversion.ndjson
Rejected files: homepage-team-01.webp, pricing-screenshot.webp
Reviewer: Design lead

This record helps when a client asks what changed or when a future teammate needs to repeat the workflow. It is also useful when an image looks different after being uploaded to a CMS, because you can distinguish local conversion from later platform processing.

Use Local Tools Deliberately#

Browser and command-line tools can process images locally when they are built that way. GetWebP is designed around that local-first model: conversion happens on the device, originals are not modified, and outputs can be written to a separate folder.

GetWebP's security overview gives the boundary that matters for client work: the CLI reads image files from disk, converts in memory, and writes outputs locally; image bytes are not sent to GetWebP. Licensing, status, or logout checks may still contact GetWebP services, so avoid describing the workflow as completely offline unless that has been tested for the client's environment.

The technical foundation matters. The GetWebP CLI command reference documents the local conversion flags, and the JSON output guide explains the NDJSON report that can be kept with the job. Google's WebP documentation explains the format, and MDN's WebAssembly documentation explains the browser runtime that makes serious local processing possible.

Still, do not rely on marketing language alone. Verify whether a tool uploads image bytes, whether it logs files, and whether it preserves originals by default.

Handoff the Approved Outputs#

When the batch passes review, hand off only the approved optimized folder and the processing note. Keep originals in the project archive, not in the upload folder where someone may publish the wrong files by mistake.

A no-upload workflow is not complicated. It is a set of careful defaults: isolate the project, preserve originals, resize intentionally, convert locally, review in context, and document what passed. Those habits make image compression safer for client work without slowing the team down very much.