Browser Filesystem Api vs Cookies
Two browser storage mechanisms that get confused only by people who haven't built anything. One holds real files; one holds a 4KB string that tags along on every request. They don't compete — they barely overlap — but if you're choosing between them for client-side persistence, the answer is not close.
The short answer
Browser Filesystem Api over Cookies for most cases. If the job is storing data in the browser, the File System Access API gives you real, large, structured local storage that never touches the network.
- Pick Browser Filesystem Api if need to read or write actual files — large blobs, user documents, exported data — kept locally and never round-tripped to a server
- Pick Cookies if need a small token the server reads on every request: session IDs, auth, CSRF, A/B flags. That's the only job cookies are good at, and they're irreplaceable at it
- Also consider: They're not substitutes. Use cookies for server-side identity, the Filesystem API (or IndexedDB/OPFS) for client-side data. Reaching for cookies as 'storage' is the actual mistake.
— Nice Pick, opinionated tool recommendations
What they actually are
The File System Access API lets a web app open, read, and write files on the user's disk (or, via OPFS, a fast sandboxed private store) — gigabytes of structured, binary-capable storage with streaming reads. It's storage in the literal sense. Cookies are a different species entirely: tiny key-value strings, capped around 4KB each, that the browser automatically attaches to every HTTP request to the matching domain. Their whole reason to exist is that the server gets to read them on the way in. That's a feature for sessions and a curse for storage — every kilobyte you stuff into a cookie is a kilobyte added to every page load, image, and API call. Calling cookies 'storage' is like calling a postage stamp 'luggage.' They share the word and nothing else. If your mental model treats them as interchangeable, you've already shipped a bug.
Capacity and performance
This is a rout. The Filesystem API and OPFS handle megabytes to gigabytes, with synchronous access handles in workers fast enough for SQLite-in-the-browser. You stream, you seek, you store binary. Cookies give you ~4KB per cookie and a soft ~50-cookie-per-domain ceiling, and crucially they tax you on every request — bloated cookies measurably slow down an entire site because they ride along on assets that have nothing to do with the cookie. I've watched teams jam JSON blobs into cookies and then wonder why their CDN bills and TTFB crept up; the answer was in the request headers the whole time. For anything beyond a session token or a feature flag, cookies are not slow storage — they're a performance regression you opted into. The Filesystem API keeps your data off the wire entirely. No contest.
Security and privacy
Cookies are the most-attacked surface on the web for a reason: they auto-send, so XSS, CSRF, and token theft all orbit them. You mitigate with HttpOnly, Secure, SameSite — and HttpOnly means JavaScript can't even read them, which is correct for auth and useless for storage. The Filesystem API never auto-transmits anything; data sits locally and goes nowhere unless your code sends it, which shrinks the attack surface to your own logic. The flip side, fairly: the Filesystem API demands an explicit user permission prompt and a user gesture, and real-disk access carries its own scary-prompt UX. OPFS sidesteps the prompt with a private sandbox. So cookies win at one narrow thing — being a server-readable credential — and lose everywhere else. Don't mistake 'familiar' for 'safe.'
Support and ergonomics
Cookies are universal — every browser since the Cretaceous, server frameworks bake them in, libraries everywhere. Zero adoption risk. The File System Access API is the weaker story here: Chromium-based browsers support the full real-disk API, but Firefox and Safari hold back on the picker-based surface, though OPFS is broadly supported as the cross-browser path. So if you need true 'save to user's Downloads folder, any browser,' you're not there yet without fallbacks. That's the one honest knock against the pick — and it's a maturity gap, not a design flaw, narrowing every release. Ergonomically the Filesystem API is a clean async/Promise interface; cookies are a stringly-typed document.cookie horror show that everyone wraps in a library to avoid touching directly. Neither is delightful, but only one of them is delightful by accident.
Quick Comparison
| Factor | Browser Filesystem Api | Cookies |
|---|---|---|
| Capacity | MB to GB; streaming, binary-capable | ~4KB per cookie, ~50 per domain |
| Network overhead | None — data stays local | Sent on every matching HTTP request |
| Server readability | Never sent to server automatically | Auto-attached; server reads every request |
| Browser support | Full API Chromium-only; OPFS broad | Universal, every browser |
| Right tool for client-side data | Purpose-built local storage | Abused storage; built for sessions |
The Verdict
Use Browser Filesystem Api if: You need to read or write actual files — large blobs, user documents, exported data — kept locally and never round-tripped to a server.
Use Cookies if: You need a small token the server reads on every request: session IDs, auth, CSRF, A/B flags. That's the only job cookies are good at, and they're irreplaceable at it.
Consider: They're not substitutes. Use cookies for server-side identity, the Filesystem API (or IndexedDB/OPFS) for client-side data. Reaching for cookies as 'storage' is the actual mistake.
Browser Filesystem Api vs Cookies: FAQ
Is Browser Filesystem Api or Cookies better?
Browser Filesystem Api is the Nice Pick. If the job is storing data in the browser, the File System Access API gives you real, large, structured local storage that never touches the network. Cookies are a 4KB envelope stapled to every HTTP request — built for server-readable session state, not storage. For client-side persistence, the Filesystem API wins on capacity, performance, and not leaking your data into every request header.
When should you use Browser Filesystem Api?
You need to read or write actual files — large blobs, user documents, exported data — kept locally and never round-tripped to a server.
When should you use Cookies?
You need a small token the server reads on every request: session IDs, auth, CSRF, A/B flags. That's the only job cookies are good at, and they're irreplaceable at it.
What's the main difference between Browser Filesystem Api and Cookies?
Two browser storage mechanisms that get confused only by people who haven't built anything. One holds real files; one holds a 4KB string that tags along on every request. They don't compete — they barely overlap — but if you're choosing between them for client-side persistence, the answer is not close.
How do Browser Filesystem Api and Cookies compare on capacity?
Browser Filesystem Api: MB to GB; streaming, binary-capable. Cookies: ~4KB per cookie, ~50 per domain. Browser Filesystem Api wins here.
Are there alternatives to consider beyond Browser Filesystem Api and Cookies?
They're not substitutes. Use cookies for server-side identity, the Filesystem API (or IndexedDB/OPFS) for client-side data. Reaching for cookies as 'storage' is the actual mistake.
If the job is storing data in the browser, the File System Access API gives you real, large, structured local storage that never touches the network. Cookies are a 4KB envelope stapled to every HTTP request — built for server-readable session state, not storage. For client-side persistence, the Filesystem API wins on capacity, performance, and not leaking your data into every request header.
Related Comparisons
Disagree? nice@nicepick.dev