My Tool Studio
Bulk Operations·4 min read

Bulk Rename Patterns Explained: {n}, {orig}, Padding

DSC_4821.JPG tells you nothing: not the shoot, not the date, not where it belongs among ten thousand siblings. Fixing that across a whole memory card is a pattern problem, and this is rename patterns explained from the batch side, how two small tokens, a start number, and a padding value turn an anonymous camera dump into a dated, sortable set. The pattern is trivial to write and easy to get subtly wrong, which is what the preview is for.

Open the toolAll insights

Bulk rename patterns explained in two tokens

Everything else is literal text.

The entire pattern language here is {n} and {orig}. The {n} token becomes a sequence number, counting up from your Start at value and zero-padded to the Padding width. The {orig} token becomes the file's original base name, extension excluded. Every other character in the pattern is copied through exactly as typed.

There's deliberately no date token, no regex, no conditional logic. Dates go in as literal text you write yourself, which sounds primitive but has a real benefit: the preview shows precisely what you'll get, because nothing in the pattern is computed behind your back except the number.

Cleaning camera filenames in one batch pass

From DSC_4821 to something searchable.

Camera bodies name files for their own bookkeeping, not yours, and cleaning camera filenames is the renamer's signature job. The standard scheme puts an ISO date first, a human label second, and the counter last: 2026-07-03-shoreline-{n}. Date-first names sort chronologically in every file manager on earth, and the label makes the folder searchable by memory.

Resist the urge to encode everything into the name. Client, location, camera body, lens, that's what folders and metadata are for. A name needs to sort correctly and jog recognition; three parts do that, seven parts just guarantee typos.

Sequential numbering schemes that survive sorting in a batch

Padding is the difference between order and chaos.

Sequential numbering schemes live or die by zero padding. Unpadded, a folder sorts as 1, 10, 11, 2, and every gallery upload or script that walks the directory inherits that scramble. Padding 3 produces 001 through 999 and keeps alphabetical order identical to numeric order, which is the entire point of numbering files at all.

Match the padding to realistic batch sizes, 3 covers almost any shoot, 4 if you archive relentlessly, and keep it constant across a project. The Start at value earns its keep on multi-card days: if card one ended at 214, start card two's run at 215 and the two batches interleave into one clean sequence.

A worked batch: one memory card, one dated set

Pattern in, ZIP out.

Load 214 files, set the pattern to 2026-07-03-shoreline-{n}, Start at 1, Padding 3. The preview immediately shows the first five mappings. Input: DSC_4821.JPG gives 2026-07-03-shoreline-001.JPG; input: DSC_4822.JPG gives 2026-07-03-shoreline-002.JPG, extensions carried over untouched.

Numbers follow list order, the order files were added, counting up from Start at. Run it and the whole set arrives as renamed.zip while the originals on disk keep their old names, so the operation is reversible by simply deleting the archive and trying again.

Want the old names preserved inside the new ones for traceability? Switch the pattern to 2026-07-03-shoreline-{n}-{orig} and the same input becomes 2026-07-03-shoreline-001-DSC_4821.JPG. It's uglier, but when a client references an original frame number six months later, you'll find it with a search instead of an archaeology dig.

Batch rename mistakes that end in silent overwrites

The pattern errors that actually cost files:

  • Writing a pattern with no {n} for a multi-file run, so every entry shares one name and later files replace earlier ones inside the ZIP.
  • Padding 2 on a 300-file batch, which works perfectly until file 100 breaks the sort.
  • Adding files in random order and assuming the numbers will match shooting order anyway.
  • Putting slashes or colons in the pattern and producing names some systems refuse to extract.
  • Renaming the only copy's folder structure by hand afterward instead of keeping the ZIP as the clean deliverable.

Reading the preview before you run the whole batch

Five rows tell you almost everything.

The preview shows the first five before and after pairs, and those five rows expose most pattern bugs: a missing {n}, a typo in the date, padding that doesn't match your intent. Check that row one starts at the number you meant and that the extension survived, then scale to the full batch with confidence.

What five rows can't show is the tail of the sequence, so do the arithmetic once: Start at plus file count minus one is your highest number. If it needs more digits than your padding allows, widen the padding before running, not after.

Bulk File Renamer versus the names other batch tools assign

Prefixes happen whether you plan them or not.

Several batch tools on this site rename as a side effect: the Bulk Image Compressor prefixes outputs with compressed-, and the Bulk Image Converter swaps extensions to match the new format. Those automatic names are collision-safe but generic. When deliverables need to follow your scheme, run the processing tool first, extract its ZIP, then bring the results here for a proper dated pattern. The renamer is likewise the fix before a conversion run when a folder holds duplicate base names waiting to collide.

Try it now

Open Bulk File Renamer

The tool is one click away. No sign up, no upload, no payment.

Open Bulk File Renamer