Ok, I spent time this morning testing each of these in order below:
According to Brave Search (Answer with AI):
This behavior typically indicates a corrupted or broken content filter list
within Brave Shields, specifically the EasyList Cookie filter, which was the
cause of a widespread incident in January 2024 where sites would not load or
load as blank text until Shields were disabled and reloaded.
To resolve this, you should:
Navigate to Brave Shields settings and locate the Content Filtering section.
Disable the “EasyList Cookie” filter (or any custom third-party filters you have added).
Restart the browser to ensure the changes take effect.
Nope, problem persists, completely reproducible.
If the issue persists, it may be due to a corrupted browser profile caused by a
power failure or crash. In such cases, removing the Brave profile folder and
restarting the browser can restore functionality.
Removed my (Default) profile and re-created it – lots of work – .
Nope, problem persists.
If you are using custom
adblock rules or third-party DNS blockers like AdGuard or Pi-hole, these can
also conflict with Shields; try disabling them to isolate the problem.
Nope I’m not. NA.
According to Brave Search (Answer with AI): The behavior you are
describing—where the Shields Status page (brave://settings/content/braveShields)
appears empty until you manually reload it after disabling Shields on a site—is
a known interface lag or caching issue in recent versions of Brave.
It’s a known issue - ok great.
Why the List Appears Empty Initially
The Shields Status page does not always update in real-time when you toggle the
Shield icon in the address bar. The list of sites with “Shields Down” is
populated from a local database that may not refresh automatically upon your
return to the settings page.
Problem is easily reproducible by restarting Brave then go to that settings page – its wrong
until you manually Reload the page.
The Reload Fix: Clicking the Reload button on the
brave://settings/content/braveShieldspage forces the browser to re-query this
database, at which point the site you just modified appears correctly in the
list.
Yep.
Not a Functional Failure: This is purely a display bug in the settings UI; the
Shields are actually disabled for the site immediately, even if the list doesn’t
show it until refreshed.
Recent Context & Related Issues
This UI lag has been noted alongside other Shields-related inconsistencies in
2025 and 2026:
Misleading,
It’s not a “lag” – it never displays the list of Shields-Disabled sites
until you manually Reload the page. It’s not like wait a while and it’s ok.
GitHub Issue #50596 (Oct 2025): Users reported that “Shields Down entries… no
longer appear until a new one is added,” confirming that the list fails to
populate dynamically without a manual refresh or a new entry trigger.
Again Nope: I disable Shields for a site, Shields Down display is empty, go disable
another site, Shields Down displays still empty, repeat. It’s not until I
manually Reload the page that it’s good.
--
The bigger meta issue: Where are the automated tests?
I’ve been running Brave Browser on my Mac and iPhone for like 8 years
and every couple of months I encounter yet another completely-reproducible
Shields or cookie clearing bug that should have been caught by an automated test.
So why do these bugs keep getting released?
Each taking multiple months to get fixed .
For a privacy-focused browser – which is why I run Brave – you’d think
the development and release process would include automated tests.
But apparently not. Which makes no sense.
I’m remembering the clear-all-state-on-browser-exit feature which was broken for months!?