Spots 
You're building a little in-browser markdown editor. "Save" is one line: turn the textarea into a Blob, wrap it in an <a download>, click it programmatically. Ship it, feels great in your own testing — you save once, done.
A real user opens notes.md, edits it, hits Save. Then edits it again, hits Save again. Then again. They go looking for their notes later and their Downloads folder has notes.md, notes (1).md, notes (2).md, notes (3).md — four files, three of them stale, and no indication which one is the one they actually want. They didn't do anything wrong. Your "Save" button was never a save button. It was a "make a new file" button that happened to reuse a familiar icon. The wrong way, and why it feels right
Here's the pattern, and it's everywhere — CodeSandbox-style playgrounds, browser-based note apps, config generators, anything that needs to hand the user a file:
It works, in the sense that a file lands on disk. But look at what it actually is: <a download> triggers the browser's download pipeline, and the download pipeline has exactly one job — write a new file, and if the name collides, rename it so it doesn't clobber anything. That collision-avoidance is a deliberate safety feature of downloads in general (you don't want a sketchy site silently overwriting your existing files), and it's exactly the behavior you don't want from a save button. There is no API call in that snippet that means "update the file the user already has open." There's no handle to the original file at all — just a one-shot blob with a suggested name.
Try it below and watch a simulated Downloads folder fill up — every click is a new file, even though it looks and feels like "saving." Runs right in your browser — poke at it and watch the concept react live. What was actually missing: a handle
The gap isn't in your code, it's in the platform. A regular <input type="file"> gives you a File object — bytes, a name, a size — but reading it doesn't hand you any way to write back to that same path. Browsers spent two decades treating "the filesystem" as something a web page should never be allowed to touch, for good reason: letting arbitrary sites read or overwrite files by name would be catastrophic. So <input type="file"> and <a download> were built to avoid ever creating that connection.
The File System Access API is what closes that gap, deliberately and with permission gates at every step. window.showOpenFilePicker() doesn't just return a file's contents — it returns a FileSystemFileHandle, a persistent reference to that specific file that your page can ask to write to later: Saving back is where the difference actually shows up. You write through the same handle you opened:
No new filename, no collision to resolve, no (1) appended anywhere. createWritable() opens a stream to the exact file the handle points at; write() sends the new bytes; close() commits them — until then the new bytes go to a temporary file (it starts empty, since keepExistingData defaults to false), and the original is only replaced when the stream closes. Same file, every time — which is the one property a save button actually needs and the download link structurally cannot provide.
That's not a toy example above — it's real. Try the second panel in the playground: pick an actual file from your machine, edit it, hit Save (Chrome asks once whether the site may save changes — that's the permission gate), then check the file on disk. It changed. Same file, same name, no sibling copies. The part that has to stay honest: this is Chromium, not "the web"
This is the part every "just switch to the File System Access API" take glosses over: Firefox and Safari don't implement the part that matters here — the file pickers. They do ship the handle-and-stream half (FileSystemFileHandle, getFile(), and since Safari 26 in September 2025, createWritable()), but only for the sandboxed origin private file system (navigator.storage.getDirectory()), which never touches the user's real files. The half that hands a page an actual file — showOpenFilePicker(), showSaveFilePicker(), showDirectoryPicker() — isn't "not yet, check back next release": WebKit's standards position is "oppose" on security grounds, and Mozilla's is "negative". Chrome, Edge, Opera and most other Chromium browsers support the pickers (Brave ships them switched off); that's the whole list.
You're building a little in-browser markdown editor.