Batch renaming & file workflow automation

Picture the end of a shoot: 300 JPGs, 50 RAW files, a handful of scanned client PDFs, and a spreadsheet of filenames the client wants matched. Renaming them one by one isn't an option, and the built-in "select all and rename" only appends "(1)", "(2)". Shell scripts can do it, but one wrong regex turns the whole folder to chaos.

The reliable approach is a rule-based renamer that applies patterns across every file type in a single pass:

• Prefix / suffix — add client-name_ or _final to every file at once.
• Find and replace — swap DSC_ for wedding_ across all 300 files in one click.
• Counter sequences — number files 001, 002, 003 from any starting value, with any padding.
• Case transforms — convert filenames to lowercase, UPPERCASE, or Title Case in bulk.
• Extension isolation — the engine changes only the name, never the format. JPG stays JPG, PDF stays PDF. This is exactly the part manual scripting tends to get wrong.

Sort the list by name, date, size, or extension first (rename by creation date to get chronological filenames), and filter to just PDFs if the client says "only the scanned docs." Done this way, 200 mixed files get renamed in about ten seconds instead of the twenty minutes it takes by hand.

This is the right thing to be nervous about. A bulk rename is a single destructive operation — there's no undo buffer to pray to once it runs. The safeguard is a live preview: old name on the left, new name on the right, updating instantly as you adjust each rule.

A preview pane does two things a blind rename can't:

• Catches collisions before they happen. If two files would resolve to the same new name (easy to do with aggressive find-and-replace), you see it in the preview instead of losing a file.
• Confirms the pattern across the whole set, not just the first file. Sequential numbering and find-and-replace touch every item, so you want to verify the rule behaves the same on file #1 and file #250.

The difference is workflow: without a preview you're stuck in "guess, undo, repeat"; with one you see exactly what will happen, spot the one file that's wrong, fix the rule, and only then commit. For irreversible conventions — renumbering a client gallery, standardizing SKU image names — that preview is the whole reason the job is safe to run in bulk.

The classic version: export 50 photos from Lightroom, convert them to WebP, resize to 1200px wide, rename them with a project prefix and counter, then compress the lot into a ZIP for the client. That's five steps across at least two tools — every single time — and again tomorrow for the next client. Each step is trivial; stacked and repeated, they eat hours a month.

The first fix is to stop reconfiguring. Save each tool's settings once as a reusable preset:

• An Image Convert set to WebP, quality 85, resize to 1200px, strip EXIF → save as "Client Deliverables."
• A Batch Rename with a project prefix and a 3-digit counter starting at 001 → save as "Client Rename."
• A Compress set to high-ratio ZIP → save as "Client ZIP."

Next time you load each preset with one click instead of dragging files and re-setting every slider and dropdown. Presets aren't limited to images — they work across any tool, so video encoding settings and PDF watermark configs get the same treatment. Configure once, recall in a click. That alone turns a five-minute reconfiguration ritual into a few clicks, before you've automated anything further.

Presets remove the reconfiguring; a folder watcher removes the clicking entirely. You point it at a watched folder — your Lightroom export directory, a shared drive, a client drop folder — assign a tool and a preset, and every new file that appears is processed automatically: converted, renamed, zipped, whatever the preset says. An event log records every action with timestamps and results, and you can pause and resume monitoring without losing track of what's already been handled.

The powerful part is chaining watchers into an assembly line:

• Folder A watches for RAW exports → converts to JPG, resizes, renames.
• Folder B watches Folder A's output → zips the renamed JPGs.
• Folder C watches Folder B's output → moves the ZIP to a synced cloud folder for client access.

Each folder is just one tool plus one preset. Chained together, they're a pipeline that runs with zero clicks after the initial export — the delivery-ready ZIP appears on its own. That's the difference between "five tools, ten clicks, five minutes" and "export to a watched folder and walk away."

Because you're not doing the job once. A one-minute task is invisible to product thinking — nobody can build a subscription around saving you sixty seconds — so the SaaS world skips it. But you run it ten times a day, and the friction compounds. Not the minute: the interruption of switching to a website, waiting for an upload, dismissing a signup prompt, and clicking download. A local utility removes all of that — the file is already on your disk, the tool is already open, and the job is done before a web page would have finished loading.

Two more reasons local wins:

• Privacy. A cloud renamer or converter means uploading client photos, contracts, and invoices to someone else's server — often a tool you found on page two of Google. A local tool never sends the file anywhere.
• Format coverage. Web converters handle the popular head of formats. The moment your job involves something off the top-ten list, the cloud option evaporates and you're back to hunting for a desktop tool anyway.

And people don't actually want a single-purpose app — they ask for an all-in-one, because the chores travel together. The same workflow that renames files also wants to convert and compress them, and bouncing between three separate sites for three steps of one task is its own friction. A shelf of small tools that share one interface beats ten polished single-purpose apps, because the value is in the adjacency.

This is the cleanup that defeats most "find duplicate files" utilities. They compare files by hash — identical bytes — so they flag the literal copy-pasted duplicate and nothing else. But the ad-agency archive problem is messier: the same photo saved at 4000px and at 1200px, a PSD next to its exported JPG, an original beside a lightly-retouched version. Byte-for-byte those are all different files, so a hash finder reports "no duplicates" while your drive is still half wasted — and on tens of thousands of large images, a naive tool crashes before it finishes.

Work it in passes, cheapest and safest first:

• Hash pass — kill the exact copies. Content-hash matching instantly finds the byte-identical duplicates: the accidental re-saves, the folder copied twice on import. This pass is safe and needs no judgment — identical means identical.
• Size and large-file pass — find the wasted weight. The redundant high-res exports are usually your biggest files. Sorting by size surfaces the 40 MB masters you've already got a delivered JPG for.
• Always review groups before deleting. No auto-delete on an archive you can't reshoot. A good tool shows each duplicate group and lets you keep the copy you choose; you commit only what you've eyeballed.

And keep it on your own disk. Uploading a client's tens-of-thousands-of-image archive to a web deduper fails on both bandwidth and confidentiality — the whole job is reading your own drive, so nothing should leave it. (See also local vs cloud file tools.)

Migrating to a new machine surfaces years of entropy at once: photos and documents spread across two or three SSDs and an aging HDD, duplicated folders, an unsorted Downloads pile, and no map of where anything lives. The tempting move — hand it to an AI agent or a one-click "cleaner" — is exactly where people lose pictures. You can't undo a bulk operation you didn't understand, and blind trust in an opaque tool on an irreplaceable archive is a bad trade.

Safe reorganization is a sequence of visible, reversible steps, not one magic sort:

• Measure before you move. Scan each drive for what's actually eating space and where. Junk is never evenly spread — it's a few giant folders, and you want to see them before touching anything.
• Prune the obvious. Surface the largest files, the empty leftover directories, and the duplicate copies, and clear those first. That routinely halves the problem before you've organized a single keeper.
• Then restructure in bulk — with a preview. Once the keepers are identified, apply one consistent naming scheme (by date, by project) across the lot, and preview every rename before it's written so New Folder (3) becomes something you can navigate.
• Keep every step local and non-destructive. A personal archive shouldn't be uploaded to a SaaS organizer or handed to a script you can't read. Each step should show you exactly what it will do first.

Do it in that order — measure, prune, restructure — and a three-drive mess becomes a clean archive without a single lost photo.

This is one of the most common quiet messes on a modern machine: a folder of hundreds or thousands of files called Screenshot 2026-03-14 at 11.42.07.png, none of which tell you anything, so finding the one with the error message or the receipt means scrolling and squinting. People care enough about it that some have built on-device AI tools just to search their own screenshots.

It helps to split the problem in two, because the halves have very different costs. One half is naming: the timestamp tells you when, but nothing about what, so the folder is unsearchable by meaning. The other half is content: the useful words are locked inside the image as pixels, invisible to your operating system's file search. A dedicated AI indexer tackles the second half by understanding each image, and that's genuinely nice — but most of the day-to-day pain is mechanical, and mechanical problems are exactly what local file tools are good at, without anything leaving your machine.

Two moves cover most of it. First, rename in bulk so the names carry something you can scan or search — a consistent prefix and a clean sequence beat timestamp soup immediately. Second, and more powerful, run OCR across the shots so the text inside them becomes real text your normal file search can match; a screenshot of an error, an invoice, or a chat suddenly turns up when you search its words. Add a duplicate pass for the accidental re-captures of the same screen and the pile shrinks and becomes findable — no cloud, no account, no handing your screen history to a service.

Two problems wearing one coat: a speed problem and a boundary problem. Solve the boundary first, because it's the one that will hurt you again on the next job.

The boundary. Unedited frames aren't a deliverable, they're working material — blinks, test shots, half-expressions. "You'll receive the curated set" is a sentence that belongs in the booking conversation, not in a negotiation at 11pm. Deliver a curated gallery and the question stops being asked.

The speed. Culling is a rhythm, and anything that breaks the rhythm costs you the evening:

• One pass, keyboard only. Advance, flag, advance. No zooming, no second-guessing — the first pass is only about "is this frame alive".
• Flag, don't delete. Rejects stay on disk and stay reversible. Deleting during a cull is how a good frame disappears.
• Pair RAW and JPEG so they move together. Handling them separately doubles the work and eventually orphans a file.
• Second pass on the keepers only. Now compare near-identical frames and pick the best of each cluster. Sharpness and open eyes decide it; this is where zoom is worth the time.
• Batch the export. One preset, applied to the final set, sized for delivery.

On RAW versus JPEG for the delivery itself: match the format to the job. Social and small prints don't need the RAW, and shooting or keeping RAW by reflex costs storage and processing time you could spend on the cull.

Sensible practice, and the fiddliness comes from cameras sorting by their own rules rather than by what you see in the file manager.

What actually determines the position:

• File name sequence, usually. Most cameras display DCIM contents in name order, so a name that sorts before your camera's own prefix puts the card first. This is the most reliable lever.
• Capture date, sometimes. Playback modes that group by date use EXIF capture time. This is why people backdate the contact image.
• Card root versus DCIM. Some bodies only index DCIM; some utilities read the root. Writing to both costs nothing and covers both behaviours.

Where it goes wrong:

• Absurd backdating. Dates far in the past or future can confuse camera firmware and software, and anything near the 2038 second-counter boundary is a genuine hazard. A modest date — a day or two before the card's first real shot — achieves the same ordering without the risk.
• Copying without verifying. A card that silently failed the write is worse than no card, because you believe you're covered. Confirm the file exists and opens on each card.
• Reformatting. In-camera formatting wipes the contact card. Re-apply it as part of your format routine or it quietly disappears.
• Overexposing yourself. Name and email is enough. A home address on a card you're trying to get back is the wrong trade.

Write the same file to every card in one pass, then verify — it's a batch job, not a per-card ritual.

These jobs share a shape: a small set of fixed output specifications, applied to material that changes. That's a pipeline, and pipelines belong in files you own rather than in a hosted template you rent.

• Write the spec down. Dimensions, format, quality, naming pattern, output folder. Once that's explicit, the job stops being design work and becomes execution. Most of the pain is that the spec currently lives in your head and gets re-derived each time.
• Make it deterministic. Same inputs, same outputs, byte-comparable. That's what lets you re-run a set after one image changes instead of redoing all of them.
• Preview the overwrite. Regenerating into the same folder should tell you what it's about to replace. Silent overwrite is how you lose a variant you'd hand-tweaked.
• Keep the raw captures separate from the exports. Sources in one folder, generated output in another, and never edit in the output folder.
• Name by variant, not by date. pricing-6.7in-en.png beats Screenshot 2026-07-22 at 14.03.11.png — you'll be diffing versions of the same variant, not browsing chronologically.
• Expect to re-run everything. A store requirement changes, a device size is added, a headline gets rewritten. If regenerating the full set is a click, that's fine; if it's an afternoon, you'll ship the stale one.

The multi-monitor wallpaper case is the same problem with a preview loop attached: keep per-display crop specs as reusable presets so reconnecting a screen doesn't mean redoing the work.

Screenshots are the least-managed files most people own: captured constantly, named by clock, never sorted, and frequently containing API keys, account numbers, or a customer's name in a sidebar.

Treat it as a short lifecycle rather than a capture habit.

• Rename at the point of use, not at capture. You won't retitle every screenshot, and you don't need to — but the moment you send or file one, give it a name describing what it shows. Those are the ones you'll look for.
• Redact before sharing, and check the edges. The obvious field is easy to blur; the leak is usually elsewhere — a browser tab title, a notification, an autocomplete dropdown, a username in the corner.
• Redact destructively. Drawing a black rectangle in a layered editor and exporting a layered format leaves the content underneath. Export flat, then re-open the export and confirm.
• Strip metadata on the way out. Screenshots carry device and sometimes location data you have no reason to hand over.
• Trim recordings before sending. The dead air at the start and the fumbling at the end are most of the file size and all of the awkwardness.
• Keep originals; export copies. Same rule as photos — the redacted, resized version is a derivative, not a replacement.
• Make the folder searchable. OCR over the screenshot folder is a genuinely good trick: it turns "the screenshot with the error about the missing token" into a search rather than a scroll.

The constraint that rules out most products is the one you put last: index in place. Many tools want to become your library — import, reorganise, rename, own the folder structure — and across a NAS that's a migration you can't easily reverse. What you want behaves more like a filename indexer: point it at chosen drives and network paths, build an index beside them, leave the files alone.

What that implies:

• The index is a separate, rebuildable artifact. If losing the index would mean losing organisation, the tool reorganised something. A good one can be deleted and regenerated from the files.
• Network paths need different handling from local disks. Scanning a NAS over SMB is far slower than a local drive, and an indexer that doesn't cache aggressively will rescan and hammer the share. Ask whether it stores per-file hashes or modification times so a rescan only touches what changed.
• Video costs much more than photos. A photo is one embedding. Video has to be sampled into frames, and how many frames per minute is the entire cost-versus-recall tradeoff. Tens of thousands of photos is routine; hundreds of hours of video is a different scale, and worth testing on one folder before committing.
• Expect semantic search to be fuzzy by nature. "Pizza" returns pizza and things resembling pizza. It's a shortlist tool rather than a lookup — which is fine, given the alternative is scrolling.

Two things help more than people expect and cost far less than the AI layer: making sure existing metadata is intact, since dates and GPS narrow a search enormously before any model is involved, and getting filenames and folders consistent first. A semantic index over a well-named archive is a much better experience than one over a pile of IMG_0472.JPG, because you can combine "pizza" with a year and a place and actually land on it.

Treat it as a pipeline with stages and artifacts rather than as one long automation, because the failures are all at the boundaries and a monolithic script gives you no way to retry just the part that broke.

Four stages, each writing files the next one reads: URL list → captures → normalised images → deck. Get the middle two right and the rest is straightforward.

What determines whether the captures are usable:

• Consistent viewport state. Fixed window size, fixed device pixel ratio, and the same zoom for every page, or the deck is visibly inconsistent and useless as audit evidence. Log the settings alongside the run.
• A defined idea of "loaded". Network-idle plus a short settle is the practical rule. Lazy-loaded images and web fonts are what produce half-rendered captures, and a fixed sleep is either too slow across 300 pages or too short for the slow ones.
• Dismiss the furniture once. Cookie banners and consent overlays otherwise appear in every single capture. Handle them with a pre-step and verify on a sample before the full run.
• Deterministic filenames derived from the URL. A stable slug plus an index. This is what lets you re-run only the failures, and what makes the mapping from slide back to page auditable later.
• Explicit failure records. A page that times out or 404s must produce a row in a report, not a missing file. On 300 pages you will have failures, and silently short decks are the real hazard — nobody notices twelve missing pages in a 300-slide deck.

Then normalise deliberately: resize to the slide's target dimensions with a fixed rule for tall pages — full-height scaled down, or first-viewport crop — decided once and applied to all. Mixed rules make the deck look broken.

For the deck itself, generate PPTX from the file set rather than driving PowerPoint's UI, keep one page per slide with the URL and capture timestamp in the slide notes or a caption, and preserve the ordering of the source list. The result is editable, which is the point — an audit deck gets annotated after it is built.

Keep the run reproducible: the URL list, the settings, and the failure report stored beside the output. Six weeks later, "was this the state on the 14th?" has to be answerable.