A website that edits a photo, opens a project folder, or saves a document directly to your computer can feel almost like a desktop app. That convenience often comes from the File System Access API. It is powerful, but its power is bounded by an important rule: a site should reach only the files or folders you deliberately choose.
Understanding that boundary makes permission prompts much easier to judge. The right question is not simply whether a website “has file access.” It is which item you selected, what kind of access you granted, and whether the browser may remember that choice.
File System Access API privacy starts with selection
The File System Access API lets compatible web applications work with files and directories on a local or network file system. According to MDN’s File System API overview, a site can receive handles for files and folders, then use those handles to read or write data when permission allows.
Crucially, a normal website does not receive a silent map of your computer. Access begins through a browser-controlled picker. You choose a file, a save destination, or a directory. The browser then gives the site a handle to that selected item, not an unrestricted pass to every document on the device.
This is why the wording and scope of the prompt matter. Selecting one image is a narrow decision. Selecting a directory can be much broader because it may include nested files and subfolders. Before approving a folder, pause and check whether it contains unrelated work, identity documents, financial records, or private family material.
What a granted website may be able to do
The capability depends on the request. Read access can let an editor open and process selected files. Read-and-write access can let it save changes back to those files, create new items inside an approved folder, or replace content. That is useful for code editors, design tools, and document apps, but it also raises the cost of trusting the wrong site.
The File System Access specification explains that access is explicitly gated through user selection and permission. It also notes that browsers should protect sensitive locations. Even so, the safest habit is to grant the smallest practical scope.
Files, folders, and save locations are different
- Open a file: the site receives access to the file you selected.
- Open a folder: the site may work with items throughout that directory, subject to the granted mode.
- Save a file: the site can write to the destination you approve.
If a task needs one document, choose one document. If an app genuinely needs a workspace, consider creating a dedicated project folder instead of granting a broad personal directory. This simple separation reduces accidental exposure and makes later cleanup easier.
Can the browser remember file access?
File and directory handles can be stored by a website, including in IndexedDB, so an app may remember a recent project. A stored handle is not necessarily the same as permanent active permission. Browsers can require the site to ask again, particularly after a new session or when write access is needed.
Permission behavior differs across browsers and versions, so treat remembered access as a convenience rather than a promise. If a site unexpectedly asks again, read the prompt instead of approving it by reflex. If you no longer use the app, remove its site permissions and stored data. Our browser permissions guide explains how to review common grants with the same deliberate approach.
What is the origin-private file system?
The API also includes an origin-private file system, usually shortened to OPFS. This storage belongs to a website’s origin and is optimized for fast app data. It is not the same as access to the folders you browse in your operating system. A web app may use OPFS for drafts, caches, databases, or offline work without placing those items in your normal Documents folder.
That distinction is helpful: a site can have its own private storage area without seeing your personal file tree. However, OPFS content still counts as website data. Clearing that site’s data may remove it, so export anything important before a cleanup. See our guide to clearing browser data safely before deleting storage you may still need.
How to make safer permission decisions
- Confirm the site and task. Grant access only when the request follows an action you just took on a service you trust.
- Choose the narrowest scope. Prefer one file over a folder, and a dedicated folder over a broad directory.
- Separate originals from working copies. Edit a copy when losing or overwriting the original would be costly.
- Keep backups. Write access means mistakes, bugs, or malicious behavior can alter selected content.
- Review permissions later. Remove access when a project ends or a web app is no longer needed.
Downloads deserve similar care. A safe permission model cannot make an untrusted file harmless after it reaches your device. Pair selective file access with the checks in our guide to safer browser downloads.
A permission prompt should create a boundary
The File System Access API is not inherently a privacy failure. Used well, it replaces clumsy upload-and-download loops with a clear, browser-mediated choice. The risk appears when a broad folder is selected without thought, write access is granted to an unfamiliar site, or old permissions are left in place.
Slow down for ten seconds. Confirm the domain, choose only what the task needs, and keep valuable originals backed up. A useful web app should work inside the boundary you set.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.