Batch-Renaming Users' Files With No Backend: File System Access API, the Firefox/Safari Fallback, and Why I Ship a ZIP Anyway

Nibbo — Mon, 02 Nov 2026 08:10:18 +0000

A small feature request: "I have 80 invoice PDFs called invoice (12).pdf. Can your tool rename them to 2026-10-15_Acme_550.00.pdf based on what's inside?" Reading the PDF and extracting the date, vendor and amount is the fun part. Actually renaming the files on the user's disk turned out to be the tricky part. Here are the three approaches I tried.

Option 1: File System Access API

Chromium browsers let you ask for a directory handle and write to it:

const dir = await window.showDirectoryPicker({ mode: 'readwrite' });
for await (const [name, handle] of dir.entries()) {
  if (handle.kind !== 'file' || !name.endsWith('.pdf')) continue;
  const file = await handle.getFile();
  const newName = await buildName(file);
  if (handle.move) await handle.move(newName); // in-place rename
}

When it works, it's magical: files are renamed in place, no downloads. The catches:

Availability. showDirectoryPicker is Chromium-only. Firefox and Safari don't ship it.
move() support for user-picked files arrived later than the rest of the API. Feature-detect it; the fallback is "write a new file with getFileHandle(newName, { create: true }), copy the bytes, then removeEntry(oldName)", which is slower and not atomic.
Permission prompts. The user gets a scary "let site edit files?" dialog. Explain before the prompt why you need it.
Collisions. Two invoices from the same vendor on the same day with the same amount happen more than you'd think. Check for existing names and append -2.

Option 2: download each renamed file

The universal fallback is to create an object URL per file and click a hidden <a download="newName">. It works everywhere, but:

browsers throttle or block multiple automatic downloads after the first few;
the user ends up with 80 copies in Downloads, and the originals untouched;
on mobile it's unusable.

I keep it only for one or two files.

Option 3: one ZIP with the renamed files

For batches, I settled on generating a ZIP in the browser (a streaming zip writer, STORE mode since PDFs are already compressed) and offering a single download. Renaming is just choosing the entry name. Benefits:

works in every browser, including iOS Safari;
one download prompt;
the user can review the result before replacing anything;
I can add a rename-log.csv mapping old names to new names, which accountants love.

Memory-wise, stream entries from file.stream() into the zip writer instead of reading all files into memory first.

What I ship

Chromium desktop: offer "rename in folder" (File System Access) and ZIP.
Everything else: ZIP only, no feature-gap apology dialog, just the button that works.
Always: a preview table of old â†’ new names, editable, before anything is written.

The preview table was the single most appreciated part. Extraction is never 100% right, and letting people fix one cell is better than any heuristic.

Nibbo's invoice renamer takes the ZIP route: it reads the PDFs, fills an editable table of new names, and gives you the renamed files as a ZIP, with the PDFs never leaving the machine. That matters a lot when the files are other companies' invoices.

â€” Vitalii

Your Upload Preview Shows a Black Box: Handling 3GP, WMV, AVI and MTS Files That the Video Element Can't Play

Nibbo — Sat, 31 Oct 2026 08:08:06 +0000

You build an upload form, add a nice preview with URL.createObjectURL(file) in a <video> tag, and test it with an MP4 from your phone. Works great. Then support tickets arrive: "the preview is black", "it says the file is broken", "the upload button never activates".

The file usually isn't broken. It is in a container or codec the browser simply does not decode. Here's how I deal with it.

What browsers actually play

Roughly, across current Chrome, Firefox and Safari:

Container	Typical codecs	Plays in `<video>`?
MP4	H.264 + AAC	Yes, everywhere
WebM	VP8/VP9/AV1 + Opus	Yes (Safari: recent versions)
MOV	H.264/HEVC	Often, HEVC depends on OS/hardware
MKV	anything	Chrome sometimes, Safari no
AVI, WMV, 3GP, MTS/M2TS, FLV	DivX, WMV9, H.263, AMR, AC-3…	Usually no

Old phones (3GP with AMR audio), Windows Movie Maker exports (WMV), camcorders (MTS/AVCHD) and screen recorders from 2010 (AVI) are exactly what non-technical users find in their archives.

Step 1: detect failure honestly

Don't rely on the file extension or file.type (it is often empty for MTS). Try to load it and listen:

function canPreview(file) {
  return new Promise(resolve => {
    const v = document.createElement('video');
    v.muted = true; v.preload = 'metadata';
    const url = URL.createObjectURL(file);
    const done = ok => { URL.revokeObjectURL(url); resolve(ok); };
    v.onloadeddata = () => done(v.videoWidth > 0);
    v.onerror = () => done(false);
    setTimeout(() => done(false), 4000);
    v.src = url;
  });
}

Note the videoWidth > 0 check: some browsers load audio from a file whose video codec they can't decode, giving you a black frame with sound.

Step 2: decide where to convert

Options, from cheapest to most robust:

Accept and convert server-side with ffmpeg. Most reliable, but you pay for compute and you now store users' family videos.
Convert client-side with ffmpeg.wasm. No server cost and better privacy, but slow on phones and memory-limited for files over ~2 GB.
Ask the user to convert first, with a clear message and a link to a tool.

For many products, option 3 is the pragmatic first step. A precise message beats a black rectangle:

"This video is in WMV format, which browsers can't preview. Convert it to MP4 first, then upload it again."

Step 3: write the message per format

Generic "unsupported format" errors make users think their file is damaged. Name the format and the fix. For the conversion link I point people to Nibbo's video converter, which turns AVI, WMV, 3GP, MTS and friends into MP4 in the browser without uploading the file anywhere, so I'm not sending users' videos to yet another third party.

Step 4: still accept the original if you can

If your backend transcodes anyway, let the upload proceed without a preview and show a thumbnail placeholder instead. Blocking the upload just because the preview failed is the worst outcome.

Summary

Probe playability with a real <video> element, check videoWidth.
Never trust file.type for legacy containers.
Name the format in the error and give a concrete fix.
Don't block the upload on preview failure.

— Vitalii

DEV Community: Nibbo