---
title: Why only Chromium browsers can save straight to disk
nav: Browsers and file access
order: 5
description: What the File System Access API is, why Firefox and Safari can only download, and why every reload asks for permission again.
updated: 2026-08-12
---

## The one-line version

Overwriting *the actual file on your disk* requires the **File System Access API**, and today only
Chromium-based browsers (Chrome, Edge, Brave, Arc, Opera) implement the full version of it.

## Web pages were never allowed near your files

The traditional `<input type="file">` hands a page a **snapshot**: you pick a file, the page reads it,
and that is a one-way trip. To give your edits back, the page can only trigger a download and let you
overwrite the original yourself — the four-step ritual of *download → open the file manager → drag it back → confirm replace*.

The File System Access API changes exactly that: once you have chosen explicitly, the page can hold a
**writable handle**, and saving really does write back to the same place.

| What this editor uses | For |
| --- | --- |
| `showDirectoryPicker()` | open a folder and list the `.md` files in it |
| `showSaveFilePicker()` | Save As |
| `createWritable()` | write new contents back into the same file |

## Where Firefox and Safari stand

Both implement the sandboxed half of the spec (OPFS, storage private to the page), but **not** the half
that reaches folders you choose yourself. It isn't a backlog item: they take a more conservative view of
the privacy trade-off. A web API that can keep writing into a user's directories is hard to walk back once abused.

So on Firefox and Safari this editor degrades to: edit, preview, copy — and saving becomes a download of a
new file. Nothing is broken; the browser simply doesn't hand out that key.

## Why permission is requested again after a reload

Permission is scoped to **this browsing session**. After a reload the page still remembers *which* folder
you used — the handle lives in IndexedDB, which is how the sidebar can offer **📂 Reopen: folder name** — but
to actually read or write it needs your consent again, and that consent has to come from your click. A page
cannot ask quietly on its own.

That is why the flow is *click Reopen → the browser asks → you allow*, rather than silent restoration.
The extra step is mildly annoying; it is also exactly what guarantees that no web page writes to your disk
without you knowing.

## Other preconditions

- **HTTPS is required.** The API is only available in secure contexts (`localhost` excepted).
- **A real user gesture is required.** Choosing a folder or saving as must start from an actual click.
- **Some files simply cannot be written.** Dropped files usually arrive read-only; the status bar then says
  *Cannot overwrite in place — use Save As*, and **Save As** solves it.

## So do the files ever leave your computer

No. This editor has no backend that could receive them — the site's only job is to hand you one HTML file.
Reading, parsing, previewing, and writing back all happen inside your browser. The full data-handling
statement is in the [privacy policy](/en/privacy).