Why Local File Renaming is Better for Your Privacy

Renaming a folder of five hundred files by hand is a chore most people solve by reaching for the first "bulk rename" tool that shows up in a search. Most of those tools work the same way: you upload your files to a server, the server renames them, and you download a new copy. It works, but it means every file — photos, documents, whatever's in that folder — passes through a computer that isn't yours before you get it back.

What actually happens when a tool "uploads" your files

An upload isn't instant and it isn't invisible. The files travel over the network to the tool's server, sit there in some form (even briefly, in memory or in a temp directory) while the renaming logic runs, and then travel back. Most tools delete the copies afterward, but that's a policy you're trusting, not something you can verify from the browser. For a folder of vacation photos or invoices, that's a real amount of trust to extend to a website you found five minutes ago.

What changed: the File System Access API

Modern versions of Chrome, Edge, and other Chromium-based browsers support the File System Access API, which lets a web page ask for permission to read and write files in a folder on your computer directly — no upload step at all. The renaming logic still runs in JavaScript, but it runs against the files where they already live. Nothing is copied anywhere else first.

This is the mechanism behind our own bulk file renamer: you grant it access to one folder, it reads the file names, applies whatever prefix, suffix, or find-and-replace rule you set, and writes the new names back to the same files. The browser's permission prompt is the only checkpoint — there's no server in the loop to trust.

Why this is also faster

Skipping the upload and download round-trip isn't just a privacy improvement, it's a practical one. Network speed stops being a factor: renaming a thousand files becomes limited by your disk, not by how fast you can push data to a server and back. On a reasonable connection, a local-first tool can finish a batch before a server-based one has finished uploading it.

Where this matters beyond renaming

The same idea applies to any tool that touches files you'd rather not hand to a third party: a EXIF stripper that removes location data from photos, or a face-blurring tool for images you're about to post publicly. In both cases, the value of the tool is partly undone if the "privacy" step itself requires uploading the sensitive file somewhere first. Local-first processing is what makes the privacy claim actually true, not just marketing language on a landing page.

The trade-off

The File System Access API isn't supported everywhere — Firefox and Safari don't implement it as of this writing, so local-first tools built on it are currently limited to Chromium-based browsers. That's a real constraint, and it's worth checking before you rely on one of these tools for a workflow you use daily. For the browsers that do support it, though, it removes the upload step entirely rather than just promising to delete your files afterward.