Safari, Chrome, Arc, Firefox, Edge: which can actually be locked down

You blocked the site in Safari and read it in Arc twenty minutes later.

Nothing malfunctioned. On a Mac there is no such thing as blocking a website. There is only blocking a website in a browser, and a Mac will happily run five of them at once, each with its own settings, its own idea of what a rule is, and its own download page about eleven seconds away.

This is the difference between the phone and the laptop, and it catches everybody who fixes the phone first. On an iPhone, the Screen Time web filter sits underneath the browsers: block a site there and it is blocked in Safari and in Chrome at the same time, with nothing done per app. macOS does not work like that. Chrome on a Mac is a whole separate program that talks to the network itself, and Apple's filter is never asked for an opinion.

There are four locks on a Mac, and only one is above the browser

Worth knowing which is which before you pick a browser, because most of the advice on this subject is one of these four dressed up as all four.

• The system filter. Screen Time's web content restriction, in System Settings, held shut by the Screen Time passcode. It covers Safari.
• The managed preference. A property list owned by root that the browser reads when it launches. Chrome, Edge and Firefox all have one. There is no switch for it anywhere inside the browser, which is the entire point of it.
• The extension. Lives inside the browser, next to a toggle that turns it off. Every browser here can run one.
• Name resolution. The /etc/hosts file, and whatever DNS the Mac is pointed at. Sits under all five browsers and understands hostnames and nothing else.

Only the last one is above the browser. The other three are inside the room they are guarding.

A lock that lives inside the thing it is locking is not a lock. It is a preference.

Safari is the only browser macOS will filter for you

Screen Time on a Mac lives in System Settings › Screen Time, and its web rules are under Content & Privacy, in Content Restrictions, where Web Content offers you unrestricted access, a filter on adult sites, or an allowed-sites-only list. Choose the middle option and you get a custom Restricted list you can type domains into.

It works. It also, on a Mac, works in Safari and nowhere else. Chrome and Firefox do not see that list, are not asked about it, and will load anything on it without hesitating. People report this constantly on Apple's own forums and it is not a bug: it is the consequence of Safari being the only browser Apple wrote.

The one setting that reaches further is the third one, allowed sites only, and it reaches further than most people want. It stops being a browser setting at that point and becomes an allowlist for the whole machine, which is why the people who switch it on end up filing threads about Creative Cloud, Office and Spotify quietly failing to reach things they need. Apple's position is that this is working as designed. It is a real lock. It is also a lock on the front door of the building rather than your flat.

The honest weakness: everything above is held by the Screen Time passcode, and you know the Screen Time passcode. There is no version of this where Safari is guarded by someone other than you.

Chrome and Edge share the strongest lock that still lives inside a browser

Both are Chromium, so both read the same policy, URLBlocklist, with URLAllowlist as its opposite number. Up to a thousand entries each. The rules live in a property list under the browser's preference domain, com.google.Chrome for Chrome and com.microsoft.Edge for Edge, and the version that holds is the one at /Library/Managed Preferences/, which is owned by root.

That last detail is the whole reason to bother. There is no page in Chrome's settings where a blocklist installed this way appears with a toggle beside it. Undoing it needs an admin password and a terminal, not a click, and at eleven at night the gap between those two is the entire product.

Check it landed: chrome://policy in Chrome, edge://policy in Edge. Reload policies, find URLBlocklist, and confirm the status reads OK. If it does not say OK, you have written yourself a note, not a rule.

The honest weakness: the policy blocks URLs, not intentions. Microsoft says it plainly in Edge's own documentation, and it is equally true in Chrome: block a path and the domain is still reachable, so a person can land on the front page and click through to the thing you blocked. Block domains, not paths, and expect the odd site to route around you inside its own JavaScript.

Firefox wins, and it is one file doing the work

Firefox is not Chromium and does not use Chromium's policies. It has its own, and they are better for this particular job.

The rules go in a plain text file called policies.json, at Firefox.app/Contents/Resources/distribution/ on a Mac, or in a configuration profile under org.mozilla.firefox. Two policies matter here. WebsiteFilter takes a Block array and an Exceptions array of match patterns, a thousand entries each, and it accepts <all_urls>, which means you can block the entire internet and then hand back the six sites you actually work on.

The second is the one nobody mentions. ExtensionSettings can install an add-on with installation_mode set to force_installed, and a force-installed extension has no remove button and no disable switch in about:addons. It is simply there. No other browser on this list will do that for you from a text file, with no company, no enrolment and no mobile device management server involved.

Check it landed: about:policies.

The honest weakness: if you take the policies.json route, the rules are inside the application bundle. Replace the bundle, by downloading Firefox again, and the rules go with it. The configuration profile route survives that, and is the one to use if you think the eleven pm version of you is resourceful.

Arc has no lock of its own, and that is the whole answer

This is the section people arrive here for, so here it is without the runaround: Arc has no website blocking. Not a weak one, not a hidden one. There is no setting.

What Arc has is Boosts, and a Boost can zap an element off a page: the Shorts shelf, the recommended column, the sidebar that always has one more thing in it. That is genuinely useful when the site is one you need and the feed is the part that eats you, and it is the best answer available inside Arc itself. It is also a curtain rather than a lock. Curtains open.

Beyond that, Arc runs Chrome extensions, all of them, which means any blocker from the Chrome Web Store works and carries the flaw the whole category carries. Arc's preference domain is company.thebrowser.Browser and The Browser Company does publish a page about setting group policies, but the Chromium policy layer underneath a Chromium fork is optional, and Mac administrators trying to lock things down in Arc have ended up writing scripts that delete the extension folder on a schedule. People do not write that script when the policy works.

There is a bigger reason not to build your defences here. Arc stopped being actively developed in 2025, when The Browser Company moved to a different browser, and the company was bought by Atlassian in September of that year. Arc still gets Chromium's security updates. It is not getting a blocking feature. Whatever you build in Arc, you are building on a browser nobody is building on.

Five browsers, four locks, one table

That is the ranking the headline promised. Firefox, then Chrome and Edge level with each other, then Safari, then Arc some distance back. Bookmark it if it is useful. Then read the next bit, because the ranking is worth less than it looks.

The ranking only helps if you have one browser

Every lock in that table is a lock on one browser. Which means the strength of your setup is not the strength of the best browser in it. It is the strength of the worst one you still have installed.

Firefox with a force-installed blocker, a thousand-entry WebsiteFilter and Arc sitting in the Dock next to it is a Mac with no blocking on it. So is Chrome under a root-owned policy with Safari one click away. And a Mac always has Safari, so the count is never zero, and the other four are a two-minute download you have already done at least once.

So the first move is not picking the best browser. It is having fewer browsers. Drag the ones you do not use out of /Applications and empty the Trash, and every rule you set afterwards gets stronger for free. The second move is making the rule the same in every browser you keep, which is where the hosts file earns its keep despite being the bluntest tool here: it is one file, it sits underneath all of them, and it has its own list of ways to quietly stop working.

So the fix has to be something that is not a browser

On the phone this is already solved, and solved in exactly that shape. iOS lets an app hold a rule that the app itself cannot quietly hand back, which is why we make one: Scrappy is a small dog who stands in front of the apps you name and gets less patient the more times you knock. Polite, then surprised, then firm, then a single word, then genuinely wounded. He does not have your passcode and does not want it. Getting past him costs a treat, and a treat costs about two thousand steps of actual walking. We do not sell treats and we are not going to.

The Mac version does not exist yet. Not shipped, not in beta, not a download we can point you at, and we would rather say that than sell you a waitlist as though it were software. When it is built it will run the same three rules, quiet hours, a daily limit and an open limit, and it will sit above the browsers rather than inside one, because this article is the reason it has to.

Until then the table above is the best you can do on a Mac, and the phone in your pocket is where most evenings actually start.