Bulk File Renamer: Practical Tips and Common Mistakes

How do you rename many files at once in a browser?

Bulk File Renamer is a browser tool at onlinefree.app that renames a selected batch of local files using one rule set — find & replace, sequential numbering, or a case change — shows an old-name → new-name preview, and then packs every renamed file into a single ZIP download. No file is uploaded: only the file names and extensions are read to build the preview, and the file bytes stay in your browser until the ZIP is assembled on your own machine.

The workflow is deliberately short. You drop or pick your files, choose one mode on the rule card, fill in that mode's fields, and watch the preview table update live. Valid rows get a green check, problem rows get an amber warning, and a counter at the top reads something like "12 renamed / 3 unchanged". When the list looks right, the sticky Download ZIP button produces one archive with the new names inside; a secondary Download individually link is there if you only need a few files.

It is worth knowing what the tool deliberately does not do as of 2026. Find & replace is literal text matching, not regular expressions. You apply one mode at a time, so you cannot stack a replace and a numbering pass in a single run. There is no EXIF, date, or per-file custom naming. If your naming scheme depends on capture dates or folders, this is not the right instrument — a dedicated desktop renamer will serve you better.

Run two passes instead of fighting one rule set

The most common mistake we see people make is trying to do everything in one mode. Because Bulk File Renamer applies a single rule set per run, the reliable pattern is two passes. Pass one: use find & replace to strip the junk that your camera, scanner, or download manager injected — things like "IMG_", "Scan_2026_", or a trailing " (1)", "(2)" from duplicate downloads. Download that ZIP.

Pass two: drop the renamed files back in, switch to Add Numbers, and apply a clean sequence. Doing it in this order means the numbers you add are the numbers your files end up with, rather than numbers that later get mangled by a replacement.

If you are cleaning up assets for a website, this two-pass habit pays off twice — consistent asset names then make it much easier to reference them in generated files like a sitemap-adjacent Robots.txt & LLMs.txt Generator output, and nobody has to guess whether the hero image was called photo-final-v2.jpg or hero-001.jpg.

Why does file 100 sort before file 99?

Because the padding was too short. In Add Numbers mode you choose prefix or suffix, a padding width, a separator, and a start index (default 1). Padding of 2 gives you 01, 02 … 99, and then the sequence simply runs out of room: the hundredth file becomes 100. Alphabetically, 100 sorts before 99, so your carefully ordered folder falls apart exactly at the boundary.

The rule of thumb we use: count your files first, then pick padding equal to the number of digits in the highest index. Up to 99 files, padding 2 works. Up to 999 files, use padding 3. Anything over a thousand files needs padding 4, which also future-proofs the folder if you add files later.

Two smaller details matter just as much. The start index is not cosmetic — set it to 0 if you are matching a zero-indexed code array, and set it to 1 for human-facing file lists. And the sequence follows the order of the file list you dropped in, not a sort you did afterward, so scan the preview rows before downloading. If the order looks wrong, re-drop the files in the order you want.

Collisions, empty names and illegal characters

The preview table exists to catch three failure modes before they cost you anything. The first is a collision: two different source files resolving to the same new name, which the tool flags in amber. This usually happens when find & replace deletes the only part that made two names unique — replacing "draft" and "final" with nothing can collapse three files into one name.

The second is an empty name. If your find text matches the entire filename, the result is nothing at all, and the row is flagged rather than silently producing a nameless entry. The third is illegal characters. Windows reserves a specific set — < > : " / \ | ? * — in file names, as documented in Microsoft's naming files, paths and namespaces reference, and a rename that introduces a colon or a slash will extract badly or not at all.

There is also a case-only trap that warnings cannot fully protect you from. On case-insensitive file systems such as typical macOS and Windows setups, Photo.jpg and photo.jpg are the same file, so a case change that creates near-duplicates may behave differently on the machine you extract to. Note that a ZIP archive can physically hold duplicate entries; what fails is extraction, where one file silently overwrites the other. Wikipedia's ZIP format overview) is a useful reference on how entries and names are stored if you want to understand the failure mode.

Choosing the right case rule for the job

Change Case mode offers lowercase, UPPERCASE, Capitalize, kebab-case and snake_case. Lowercase is the safest default for anything destined for a web server or a build pipeline, because it removes the whole class of case-sensitivity bugs between macOS laptops and Linux hosts.

Kebab-case (my-long-filename.jpg) reads well in URLs and is what most static site generators expect. Snake_case (my_long_filename.jpg) is friendlier for code imports that use hyphens as minus signs. Capitalize is best reserved for human-facing documents — reports, invoices, scanned paperwork — where you want "Quarterly Report" rather than "quarterly-report".

One discipline matters more than which rule you pick: apply case changes to the name portion only, not the extension. The find & replace mode has an apply-to selector for name, extension, or both, and leaving it on both is how people turn every .JPG into a strangled variant of itself. Extensions rarely need case work, and some servers really do treat .JPG and .jpg as different files.

Verify the ZIP before you rely on it

Renaming in Bulk File Renamer never touches your originals — the tool reads them and writes a new ZIP containing copies under the new names. That is a genuine safety net, and it is also why the last step matters: open the downloaded ZIP and confirm the file count matches the renamed-count in the preview before you delete or move anything.

Check three things. Total entries in the archive. A spot-check that a renamed image or PDF still opens, since a bad extension change can leave a file that looks fine but will not launch in your default application. And the ordering in your file manager, which is where an under-padded number sequence reveals itself immediately.

Keep the original folder intact until you have verified one round end to end. There is no undo inside the tool, so if you extract over the originals and the numbering was off, you are relying on a backup rather than a button. For a plain batch-rename job that is entirely reasonable; for a folder of irreplaceable scans, verify first and trust the preview table second. For more no-upload utilities, the OnlineFree.app free online tools index covers the rest of the set.

References

• Microsoft — Naming Files, Paths, and Namespaces
• Wikipedia — ZIP (file format)