Bulk File Renamer

Two tokens plus anything literal: {n} becomes the sequence number, {orig} becomes the original base name, and everything else is copied as typed. There's no date token or regex support, so write dates directly into the pattern, like 2026-07-03-shoot-{n}.

Use a pattern such as 2026-07-03-wedding-{n} with Start at 1 and Padding 3, which produces 2026-07-03-wedding-001.jpg through however many frames you loaded. The ISO date prefix keeps every future folder listing in chronological order.

Never. Your files are read in the browser, copied under their new names into a ZIP, and the download is a fresh archive. The originals on disk keep their old names, so a bad pattern costs you a redo, not data.

Your pattern probably had no {n} token, so all outputs shared one name and later entries replaced earlier ones in the archive. Any multi-file pattern needs {n} somewhere, or {orig} if you're prefixing existing names, to keep each entry unique.

Yes, the reading, renaming, and ZIP packaging all happen locally in your browser tab. That makes it fine for contracts, client deliverables, and anything else you wouldn't hand to a random web service.

It zero-pads the sequence number to a fixed width: padding 3 gives 001, 002, 003. Padded numbers sort correctly in every file manager, where unpadded ones produce the classic 1, 10, 11, 2 ordering mess. Match padding to your batch size, 3 covers up to 999 files.

In list order, counting up from the Start at value. Files number in the order they were added, so add them in the sequence you want, or Clear and re-add if the order came in wrong. The preview's first five rows confirm the mapping before you run it.

That's exactly its job. A pattern such as final-{orig} keeps every base name and adds your prefix, so report.pdf becomes final-report.pdf. Combine both tokens, {n}-{orig}, when you want originals preserved but forced into a numbered order.