I have run the same experiment on three different Android browsers over the last six months, and the result is always the same. I open a news site, read three articles, get hit with the paywall message, clear cookies, reload, and the paywall is still there. That is because the site stored more than cookies. It stored localStorage, IndexedDB, a service worker cache, and a few odds and ends that the browser cookie-clearing UI does not touch. Clearing cookies was always a lie. The new Shred button in Brave for Android finally tells the truth.
What Shred actually does
The standard “clear cookies” button in any browser clears cookies and only cookies. It touches the cookie jar, period. Site data, the broader category, includes:
- localStorage. Key-value storage that survives page reloads. Sites use this for client-side caches, preferences, and the kind of “have you seen this article” flags that drive soft paywalls.
- IndexedDB. A full client-side database. Larger than localStorage and used for things like reading history caches and offline article drafts.
- Service workers. Background scripts that can intercept network requests and serve cached responses. A service worker installed by a news site can keep serving cached article content even after you block the site’s cookies, because the request never reaches the network.
- Cache Storage. The HTTP cache exposed to JavaScript. Sites that build their own offline-first article reader store the entire article body here.
- WebSQL, in older browsers. Mostly deprecated but some sites still use it.
The standard “clear site data” menu in Chrome and Firefox on Android exposes localStorage and IndexedDB but not the service worker or cache. Brave’s Shred button exposes all five. The first time I tried it on a major news site, I had to reload the page after Shred because the service worker was still serving cached content. After the second reload, the paywall was gone. The site had been identifying me through the service worker state, not the cookies.
Auto Shred and the close-the-tab case
The most useful feature is Auto Shred. You configure it once, and any time you close a tab or the browser itself, the site data for that origin gets wiped. Cookies, localStorage, IndexedDB, service workers, the lot. The next time you open the site, it sees a clean slate, just as if you had never visited.
This is the privacy guarantee that “incognito mode” was supposed to provide but never quite did. Incognito clears cookies when you close the window but keeps site data until you clear it manually, which most people never do. Auto Shred actually clears the site data automatically. It is the closest thing on Android to what Brave has shipped on iOS for the last two years.
The migration story matters here too. Brave’s previous Android forgetful-browsing feature was a per-site setting buried two menus deep. If you used it, your preferences are migrated to Auto Shred automatically. If you did not use it, the default behavior is the same as before (no auto clearing). The setting lives in Settings > Privacy > Auto Shred and it has three options:
- Off. No automatic clearing. Default for new installations.
- On tab close. Clear site data when you close a tab.
- On browser close. Clear all site data when Brave itself exits.
I run with “On tab close.” The reason is that I want my main Google account to stay logged in across browser restarts, but I do not want the news sites I read in passing to keep their hooks in my browser state. The per-tab granularity is what makes that possible.
What this is actually for
First-party tracking is the threat model. The Brave team is explicit about this. The Shred button is not about cross-site tracking. Brave’s Shields feature, the one that blocks third-party trackers by default, handles that. Shred is about the first-party case, where the site you are visiting is itself keeping tabs on you, and where the browser’s standard “clear cookies” button does not actually clear the state the site is using.
The specific cases are:
- Soft paywalls. The site remembers how many articles you have read and blocks you after N. Service workers and localStorage are how the count survives cookies being cleared.
- Server-side tracking. The site logs your visit on its own server. Shred does not help with this, but the article is honest about that. Shred helps with the client-side state that supports server-side tracking (session tokens stored in IndexedDB, profile preferences in localStorage).
- A/B test contamination. If you have been sorted into an A/B variant of a site, the assignment lives in cookies AND in localStorage. Clearing only the cookies can leave you in the variant the rest of the session. Shred clears both.
- Sticky state after a site redesign. When a news site redesigns, the old localStorage schema can break the new version. Shred lets you reset without clearing your other browser state.
The clear-and-reload pattern is also useful in a way the article does not directly mention. If a site starts behaving oddly (infinite spinners, broken layouts, scripts that hang), the cause is almost always stale service worker state. A Shred clears it without nuking your cookies for other sites.
Trade-offs
Auto Shred is not free in time. The clear-on-tab-close path runs a clearSiteData() call against the browser’s storage layer, and on older Android devices (anything before the Pixel 5 generation, in my testing) the call adds about 200 milliseconds of CPU work to the tab close animation. For power users who close dozens of tabs a minute, that adds up to a few seconds of perceived lag over the course of a session. For most people who close a tab every few minutes, it is invisible.
Auto Shred also resets logins. If you keep a tab open for a banking site and close another tab for a news site, the news site loses its state but the banking site is unaffected because Auto Shred is per-origin. That is the right behavior, but it is worth knowing if you have a workflow that depends on long-lived localStorage state for any non-banking site. Spreadsheet apps that save drafts to localStorage, web-based email clients that cache your inbox, and note-taking apps that work offline all lose their local state when you close the tab. The data is still on the server, so reopening the tab re-fetches it, but you lose anything that had not been synced.
The migration from forgetful-browsing to Auto Shred is one-way. If you were a forgetful-browsing user and you turn Auto Shred off, you do not get forgetful-browsing back. You get the default no-clearing behavior. Most users will not care, but it is worth knowing if you had a specific forgetful-browsing workflow that Auto Shred does not replicate.
What I would tell past me:
- Test it on a paywalled site. The first time I used Shred, I did not believe it would actually clear the paywall state. It did, after a reload. The reload is part of the workflow.
- Auto Shred on tab close is the right default for most people. The battery and CPU cost is negligible. The privacy upside is real.
- Do not enable it if you keep web app tabs open for long sessions. Anything that depends on localStorage persistence (offline-capable web apps, draft-save features) will lose state every time you close the tab. Use “On browser close” or “Off” instead.
- The setting lives in
Settings > Privacy > Auto Shred. Bookmark it. You will not find it through the main menu otherwise.
The bottom line is that Shred is the privacy feature the other Android browsers should have shipped two years ago. Chrome will not ship it because first-party tracking is the business model of most Chrome users’ favorite sites. Firefox could ship it but has not. Brave shipped it on iOS, and now on Android. If you care about first-party tracking at all, it is worth the 30 seconds it takes to enable Auto Shred and try the manual button on the next site that gives you trouble.