Your browser might be writing more to your SSD than Windows ever will

When your SSD refuses to catch a break, Windows is generally blamed as the first culprit. Between updates, background services, and temporary files, that reputation feels deserved. But the browsers you leave running all day might be doing more harm to your SSD than you think.
Browsers quietly manage far more local data than their windows suggest. Depending on how you browse, that activity could very well outweigh Windows’ routine housekeeping. The surprising part isn’t that browsers write files. It’s how many different reasons they have to keep writing them.
Your browser’s cache is really a pile of caches
HTTP, code, GPU, media, and service worker caches, all hungry
The obvious culprit is the HTTP disk cache. Edge, being Chromium-based, keeps a per-profile cache between the network stack and the web, storing downloaded resources so repeated visits can avoid another transfer. Chromium’s cache maintains indexes and eviction metadata, creating, updating, renaming, and deleting entries rather than writing each image once.
Then there are the less obvious layers. Compiled JavaScript and WebAssembly can feed a code cache that can eventually balloon in size. GPU-related data can also land in a GPU or shader cache. Streaming sites buffer or cache media separately. Extensions maintain their own data. Service workers can save HTML, CSS, JavaScript, images, and API responses through Cache Storage so sites behave like installed apps or work offline. None of these look anything like a file you’d download intentionally, yet they’re all sitting there taking space on your SSD.
Even Firefox-based browsers are no better. Zen Browser, my preferred browser at the moment, is Firefox-based and its documentation says Firefox manages its passwords, cookies, and cache. Firefox’s HTTP cache stores each disk entry as a file under cache2/entries, alongside an index, journal, and temporary index used during updates. On Windows, Firefox-style profiles can also split durable profile data under AppDataRoaming from cache and other temporary data under AppDataLocal. Chromium-based browsers tend to keep their profiles and caches together under local AppData folders.
Websites are quietly running databases on your SSD
IndexedDB, Cache Storage, and quotas that make a cookie look tiny
Cache files are only half the story. Websites persist data through cookies, local storage, IndexedDB, Cache Storage, and the Origin Private File System. IndexedDB is intended for large structured or binary data, while Cache Storage keeps request-response pairs. Web apps can therefore maintain a significant amount of data that survives reboots.
MDN says Firefox ordinarily allows an origin up to whichever is smaller of 10 percent of the profile disk or a 10 GiB per-site limit in best-effort mode, while Chromium-based browsers such as Edge can permit an origin to use up to 60 percent of total disk size. Those are quotas, not targets, but you can be pretty sure that a few tiny cookies won’t cut it anymore.
Your profile writes to disk every time you blink
SQLite, WAL files, and one page load turning into a pile of housekeeping
Ordinary navigation changes persistent browser state. Zen’s Firefox-style profile records bookmarks and history in places.sqlite, cookies in cookies.sqlite, form entries in formhistory.sqlite, and open windows and tabs in sessionstore.jsonlz4. Edge likewise stores history locally per profile, along with cookies, passwords, autofill information, settings, extensions, and open tabs.
Because many stores are databases, one logical update can cause multiple physical writes. With SQLite write-ahead logging, changed pages first go into a WAL file and later move into the main database during a checkpoint. Both stages include synchronization to persistent storage. Add favicons, permissions, extension state, safe-browsing data, crash information, session snapshots, and eviction records, and one page can create a surprising amount of housekeeping.
Windows isn’t innocent, just a lot less chatty
Bursts around updates and scans versus writes that track every click
Windows certainly isn’t innocent. Its comparable background data includes temporary files, event and error logs, the search index, thumbnail and DirectX shader caches, Defender data, Prefetch information, update downloads, and delivery optimization content. Delivery optimization automatically expires cached files and enforces a configuration size limit, with a documented default cache age of three days. Windows Search is always available as a service but throttles itself when system I/O, memory pressure, battery use, or free-space conditions become suboptimal.
The major difference is frequency. Windows maintenance is often done in bursts and generally around updates, scans, indexing, or cleanup. Browsing produces writes in direct proportion to your web activity. Every new origin, video chunk, history entry, restored tab, web-app database transaction, and extension event can touch storage. Edge can even share local browsing history data with the Windows indexer.
Pagefile.sys and hiberfil.sys should not rig the comparison. Allocated size is not bytes written, and paging reflects pressure from every process — including the browser. Microsoft describes the page file as backing infrequently accessed modified memory and supporting the system commit limit and crash dumps.
Stop counting folders and measure actual writes
Folder size is a snapshot, SSD wear is a running tally
A 2GB profile doesn’t mean only 2 GB was written. Cache entries rotate, databases journal and checkpoint, session files are replaced, and deleted space gets reused. Conversely, a huge Windows cache may have been written once and barely touched afterwards. Folder size is a snapshot; real SSD wear depends on cumulative host writes, then on the drive controller’s own write amplification.
For someone living in their browser, the program quickly becomes an always-on database engine, app runtime, media client, and cache manager. Windows may own the SSD, but the browser can keep it far busier than its innocent-looking window suggests.
