DevTools•Jun 2026•3 min read

Browser Filesystem Api vs Nodejs Fs

The browser's File System Access API and Node's fs module both read and write files, but they live in different universes: one is sandboxed and permission-gated, the other has the run of your disk. Picking the "winner" means picking the one you can actually build production tooling on today.

The short answer

Nodejs Fs over Browser Filesystem Api for most cases. node:fs is a mature, universal, fully-supported API that works everywhere Node runs.

  • Pick Browser Filesystem Api if building a browser-based editor, IDE, or local-first web app and need to read/write the user's real files with their explicit consent — there is no Node in a tab, so this is your only door
  • Pick Nodejs Fs if writing anything server-side, a CLI, a build tool, or a desktop app shell — you want unrestricted, synchronous-or-async, battle-tested file access
  • Also consider: Origin Private File System (OPFS) if you only need fast sandboxed storage in the browser and don't actually need the user's Documents folder.

— Nice Pick, opinionated tool recommendations

What they actually are

node:fs is Node's core file system module — read, write, stat, watch, stream, the whole POSIX-ish surface, available since Node existed and stable across every runtime that claims Node compatibility (Bun, Deno's node compat, serverless). It assumes it's allowed to touch your disk, because on a server it is. The browser File System Access API is a Web Platform API that lets a page request a handle to a real file or directory, then read and write it — but only after the user clicks through a picker and grants permission, and only within a sandbox the browser polices. They share a verb list and almost nothing else. One is infrastructure; the other is a carefully chaperoned guest in someone else's house. Conflating them because both say 'filesystem' is how you end up shipping code that can't run where you deployed it.

Capability and reach

node:fs wins on raw power without contest. It opens any path the process can access, does sync and async and streaming, watches directories, handles symlinks, permissions, and large files without ceremony. The File System Access API is deliberately weaker: every grant is per-handle, permissions evaporate on reload unless you re-request, writes go through a writable stream you must close, and the user can revoke at any time. That's not a bug — it's the entire security model of running untrusted code in a tab. But it means you cannot build a headless pipeline, a cron job, or a server on it. If your job is 'process 40,000 files on deploy,' the browser API isn't a contender, it's a category error. node:fs simply does the thing.

Support and portability

This is where the browser API gets embarrassing. The full File System Access API — directory pickers, writable handles to user files — is Chromium-only. Firefox and Safari support OPFS (the sandboxed private store) but not the showOpenFilePicker/showDirectoryPicker surface that lets you touch the user's actual files. So 'cross-browser File System Access' is a half-truth you'll discover in a bug report. node:fs, by contrast, is the same API on Linux, macOS, Windows, in Docker, in Lambda, in Bun, in Deno. You write it once and it runs wherever your code runs. One of these is a portability nightmare gated behind feature detection and fallbacks; the other is boring, which in infrastructure is the highest compliment I give.

The honest verdict

They don't compete — they barely overlap — but you asked me to pick, so I will: node:fs, decisively. It's the one you can build a business on. The File System Access API is genuinely good at exactly one thing the other can't do: giving a web page consented access to a user's real files for local-first apps, and for that narrow job it's the only option, so use it there and nowhere else. Everywhere else, reaching for it means you've misunderstood your deployment target. Don't let a shared word fool you into thinking you have a choice in most situations. You have a server-side default (fs) and a browser-only escape hatch (File System Access). Treat the escape hatch like an escape hatch — useful, narrow, and not where you live.

Quick Comparison

FactorBrowser Filesystem ApiNodejs Fs
Platform supportChromium-only for user-file access; Firefox/Safari only do sandboxed OPFSEvery Node-compatible runtime, every OS
Disk access scopePer-handle, user-granted, revocable sandboxAnything the process can read/write
Permission/UX frictionUser must pick and grant; permissions reset on reloadNone — assumes server trust
Server/CLI/automation useImpossible — there is no Node in a tabNative and dominant
Local-first web app file accessThe only real option for touching a user's actual filesCannot run in a browser at all

The Verdict

Use Browser Filesystem Api if: You're building a browser-based editor, IDE, or local-first web app and need to read/write the user's real files with their explicit consent — there is no Node in a tab, so this is your only door.

Use Nodejs Fs if: You're writing anything server-side, a CLI, a build tool, or a desktop app shell — you want unrestricted, synchronous-or-async, battle-tested file access.

Consider: Origin Private File System (OPFS) if you only need fast sandboxed storage in the browser and don't actually need the user's Documents folder.

Browser Filesystem Api vs Nodejs Fs: FAQ

Is Browser Filesystem Api or Nodejs Fs better?

Nodejs Fs is the Nice Pick. node:fs is a mature, universal, fully-supported API that works everywhere Node runs. The browser File System Access API is permission-gated, Chromium-only, and still missing from Firefox and Safari for the spec parts that matter.

When should you use Browser Filesystem Api?

You're building a browser-based editor, IDE, or local-first web app and need to read/write the user's real files with their explicit consent — there is no Node in a tab, so this is your only door.

When should you use Nodejs Fs?

You're writing anything server-side, a CLI, a build tool, or a desktop app shell — you want unrestricted, synchronous-or-async, battle-tested file access.

What's the main difference between Browser Filesystem Api and Nodejs Fs?

The browser's File System Access API and Node's fs module both read and write files, but they live in different universes: one is sandboxed and permission-gated, the other has the run of your disk. Picking the "winner" means picking the one you can actually build production tooling on today.

How do Browser Filesystem Api and Nodejs Fs compare on platform support?

Browser Filesystem Api: Chromium-only for user-file access; Firefox/Safari only do sandboxed OPFS. Nodejs Fs: Every Node-compatible runtime, every OS. Nodejs Fs wins here.

Are there alternatives to consider beyond Browser Filesystem Api and Nodejs Fs?

Origin Private File System (OPFS) if you only need fast sandboxed storage in the browser and don't actually need the user's Documents folder.

🧊
The Bottom Line
Nodejs Fs wins

node:fs is a mature, universal, fully-supported API that works everywhere Node runs. The browser File System Access API is permission-gated, Chromium-only, and still missing from Firefox and Safari for the spec parts that matter.

Related Comparisons

Disagree? nice@nicepick.dev