Batch filename renamer

Why the rename happens in your shell, not here

A page in a browser tab has no path to your filesystem, and that is the correct design rather than a gap waiting to be filled. The File System Access API exists in Chromium, needs an explicit directory grant, is absent from Firefox and Safari, and would still leave you trusting a web page with write access to a folder. Handing you a script instead keeps the destructive step where you can read it first, run it under your own account, and keep it as a record of what happened.

That constraint shapes the whole tool. The names come in by paste or by drop — and dropping a file only reads its name property, never its bytes. The rules are applied in memory. What comes out is a preview you can check line by line and a script that does the work. The one thing the page cannot see is the directory itself, so it cannot know whether a target name is already taken by a file you did not paste. That is why the bash script uses mv -n, which refuses to overwrite, rather than a bare mv.

Nothing is remembered between visits. There is no account, no history and no storage, so a second visit starts from an empty box. For a one-off tidy-up that is the right trade; for a rename you run every week, take the script and keep it in the project.

Getting the quoting right

The part of this that is easy to get wrong is not the renaming, it is the quoting. A filename can legally contain a space, a single quote, a dollar sign, a backtick, a semicolon, a newline and a leading dash, and a script that pastes such a name into a command unquoted will either rename the wrong thing or execute part of the name. Every name in the bash script is wrapped in single quotes, where nothing is special, and an embedded single quote is closed, escaped and reopened as '\''. Every rename line also begins mv -n --, because the double dash is what stops a file called -rf.txt being read as a set of options.

PowerShell has its own rules. Inside single quotes it expands nothing — no $variable, no backtick escapes — and an embedded single quote is escaped by doubling it. The script also uses -LiteralPath rather than -Path, because -Path treats square brackets as wildcard character classes, which is the usual reason a PowerShell rename quietly skips every file with a [1] in its name.

The warnings column exists for the same reason. Two source files mapping to one target name means a lost file, so both rows are flagged. A name that is empty, longer than 255 bytes when encoded as UTF-8, ends in a dot or a space, contains one of the characters Windows forbids, or matches a reserved device name such as CON or LPT1 gets its own line. Rows with a warning are left out of the generated scripts entirely — the preview shows them so you can fix the rule, not so you can run them anyway.

Questions people ask

Is it safe to run the script this page produces?

Read it first, then decide — and that is not a disclaimer, it is the reason the tool works this way. The script is plain text, with one mv or Rename-Item per rename and no deletions. The bash preflight has one small while/find loop that checks exact target names before any rename runs; it does not rename or delete inside the loop. Run the script from the directory holding the files, on a copy if the originals matter, and check that the file count afterwards is what you expected. The bash version also uses mv -n, so it will not overwrite anything that already exists.

Why is it warning about names that work perfectly on my Mac?

Because the warnings cover the strictest platform a file is likely to meet, not the one you are on. A colon is legal on Linux and fine in APFS, and it is forbidden on Windows and will break a checkout of the same repository there. A trailing space or dot survives on macOS and is silently stripped by Windows, so a file that opens for you does not exist for someone else. CON.txt is a reserved device name on Windows and has been since DOS. If your files never leave a Unix machine you can ignore all of it, but a filename tends to outlive the assumption that it will stay put.

What happens if two files end up with the same new name?

Both rows are flagged as a collision and neither goes into the generated script, because running it would leave you with one file where you had two. The most common cause is a case rule — Report.pdf and report.pdf both becoming report.pdf — followed by a strip pattern that removes the only part of the name that differed. The usual fix is to add sequential numbering, which makes every target unique by construction. Note that macOS and Windows treat filenames case-insensitively, so those two files probably could not have coexisted in one directory on those systems anyway.

What does the web-safe option actually change?

It decomposes each character with Unicode NFD and drops the combining accent marks, so é becomes e and Crème becomes Creme. A handful of letters are not accented versions of anything and so cannot be decomposed — ß, ø, æ, ł and their relatives — and those are mapped by hand to ss, o, ae and l. Spaces become hyphens, anything left outside A-Z a-z 0-9 . _ - becomes a hyphen, runs of repeats collapse, and leading and trailing hyphens go. Scripts that are not Latin do not survive this: a name written entirely in Japanese comes out empty, which the preview flags rather than hides.

Does dropping files here upload them?

No, and there is nothing to take on trust. The drop handler reads file.name from the drag event and nothing else — no FileReader, no fetch, no XMLHttpRequest anywhere on the page. The bytes of your files are never opened, so a folder of confidential documents is exactly as private after dropping it here as before. You can confirm it the same way you should confirm it anywhere: open the Network panel, clear it, drop a file, and watch nothing happen.