How do I block a URL in Chrome on a managed iPhone or iPad?

Add Google Chrome to your iOS/iPadOS Policy and, in its Configuration field, add the URLBlocklist property with the list of sites to block, such as ["facebook.com","x.com"].

Does the device need to be supervised?

No. Chrome's URL policies are delivered through managed app configuration, so supervision isn't required. Chrome only needs to be installed as a managed app through Applivery.

Does blocking a URL in Chrome also block it in Safari?

No. This configuration only controls Chrome. To restrict Safari, use the Web Content Filter configuration. The two mechanisms are independent.

How do I block everything except a few sites?

Set URLBlocklist to ["*"] to block every site, and add URLAllowlist with the sites you want to keep reachable.

What happens if a URL matches both the blocklist and the allowlist?

The most specific filter wins. If a block filter and an allow filter are equally specific, the allow filter takes precedence.

Does blocking a domain also block its subdomains?

Yes. An entry like facebook.com covers the domain and all its subdomains, so you don't need a wildcard such as *.facebook.com.

Why does chrome://policy show "Unknown policy"?

The properties were sent inside a wrapper key such as ChromePolicy. Place URLBlocklist and URLAllowlist directly at the root of the Configuration field.

Why can I still open a blocked site after applying the Policy?

Chrome hasn't picked up the new configuration yet. Fully close Chrome on the device and open it again, then check chrome://policy.

Block or Allow URLs in Chrome

If your users browse with Google Chrome on their iPhones and iPads, you can decide which websites Chrome is allowed to open — block a couple of distracting sites, or lock Chrome down to a short list of work tools. You do it from the Chrome app entry in your Policy, through its managed app configuration.

Chrome vs. Apple's Web Content Filter

These properties only control Google Chrome. If you need to restrict Safari, use Apple's native Web Content Filter instead. The two mechanisms are independent: blocking a URL in one doesn't block it in the other.

	Chrome URL blocking	Web Content Filter
Scope	Google Chrome only	Safari and WebKit
Where you set it	Policy → Apps → Google Chrome → Configuration	Policy → Web Content Filter configuration
Supervision required	No	Yes

Prerequisites

Google Chrome is added as an app in your iOS/iPadOS Policy. The configuration only reaches Chrome when it's installed as a managed app.
The device doesn't need to be supervised.
Access to a test device, so you can check the result in chrome://policy.

Configuration

Open your Policy

In the Applivery Dashboard, go to Policies 1 and select your iOS/iPadOS Policy.

Open Google Chrome

Go to Apps 2, and add or edit the Google Chrome 3 entry.

Add the properties

In the Configuration field, add URLBlocklist (and URLAllowlist if you need exceptions). You can use either JSON mode or Property mode — both produce the same result. See the examples below.

Save and apply

Save the changes and apply the Policy to your devices.

Restart Chrome on the device

Fully close Chrome and open it again so it picks up the new configuration.

Blocking specific sites

JSON mode — paste the object with the list as a JSON array:

{
  "URLBlocklist": [
    "facebook.com",
    "x.com"
  ]
}

Property mode — click + Add Property and fill it in:

Key: URLBlocklist
Value: ["facebook.com","x.com"]

Allowing only a list of sites

Block every site with *, then list the exceptions in URLAllowlist:

{
  "URLBlocklist": [
    "*"
  ],
  "URLAllowlist": [
    "mail.google.com",
    "applivery.com"
  ]
}

In Property mode, add two properties: URLBlocklist with the value ["*"], and URLAllowlist with the value ["mail.google.com","applivery.com"].

Warning

Add the properties at the root. URLBlocklist and URLAllowlist go directly in the Configuration field. Don't wrap them in a container key such as ChromePolicy — Chrome will show them as Unknown policy and ignore them.

URL filter syntax

Entries follow Chrome Enterprise's filter format, [scheme://][.]host[:port][/path][@query] — the same syntax Applivery uses on every platform where URLBlocklist and URLAllowlist are available.

Entry	What it matches
`facebook.com`	The domain and all its subdomains. You don't need a separate `*.facebook.com` entry.
`.www.example.com`	Only that exact host. Other subdomains stay reachable.
`*`	All hosts. It's a special value on its own, not a wildcard you can put inside a hostname.

Note

When the two lists collide, the most specific filter wins. Chrome selects the filters with the longest matching host, then the longest matching path, then the longest set of query tokens. If a block and an allow filter are equally specific, the allow filter takes precedence.

For the full syntax reference, with more examples and special cases, see URL Filters.

Checking it applied

On the device, open Chrome and go to chrome://policy.
Tap Reload policies.
Find URLBlocklist and URLAllowlist: the Status should be OK and the Value should match what you configured.
Try to open one of the blocked sites. Chrome should show its blocked-page message.

Troubleshooting

What you see in `chrome://policy`	Likely cause	What to do
Status Error	One of the entries isn't valid syntax — for example `*.domain.com`, with a wildcard before the host.	Check each entry against the URL Filters syntax. Remember a bare domain already covers its subdomains.
Status Unknown policy	The properties were sent inside a container key such as `ChromePolicy`.	Move `URLBlocklist` and `URLAllowlist` to the root of the Configuration field.
Status OK, but the site still opens	Chrome hasn't been restarted since the Policy was applied.	Fully close Chrome and open it again.
An allowed site is still blocked	A more specific entry in `URLBlocklist` is matching it, or another app configuration on the same device conflicts.	Check which filter is more specific, and make sure no other configuration for Chrome is applied to the device.

Blocking the website isn't blocking the app

These properties only stop access through Chrome. If a service has its own native app, users can keep using it there. To stop people using the service itself, also block the app — see Block & Allow Apps.