For an internal extension, private visibility is usually the right choice, because it limits installation to trusted testers, Google Groups you manage or, where enabled, your Workspace domain. Unlisted is not private: anyone who knows the store URL can install it. Public lists it for everyone.
The three options
Chrome's distribution documentation describes them as follows.
| Visibility | Who can install | Listed in search |
|---|---|---|
| Public | Everyone | Yes |
| Unlisted | Anyone who knows the Chrome Web Store URL | No |
| Private | Specified users only, typically used for testing before launch | No |
The documentation also states a key point: all visibility settings have the same policy requirements and go through the same review process. A private extension is not exempt from store review.
Private has three audiences
- Trusted testers. You list Google Account emails in account settings. The list belongs to the account, not an individual item.
- Google Groups. You can add groups you own or manage, on a per-item basis. Members and trusted testers can install.
- Domain publishing. Available only for Google Workspace domains where the domain administrator has enabled it. It adds a further option on the distribution page.
How to choose
- Tool only your staff need, and you use Workspace. Private with domain publishing is the tightest match, once your administrator enables it.
- Tool for a partner group. Private with a Google Group you manage.
- Tool for any customer. Public, with a full listing and privacy disclosures.
- A link you will share by email. Unlisted is tempting, but treat the URL as public. A forwarded link works for everyone.
Mistakes to avoid
- Using unlisted for secrets. If the extension embeds internal URLs or logic, unlisted offers no confidentiality. Anyone with the link can download it.
- Assuming private means unreviewed. The same policies apply, so do not put workarounds in the code.
- Forgetting access hygiene. Trusted testers and group membership are access lists. Review them when people leave.
Pair visibility with force-install
Visibility controls who can install from the store. Policy controls who gets it automatically. Typically you publish privately and then force-install through policy to the right groups. See what force-installing grants before you do.
For a different route, the self-hosting requirements article covers hosting outside the store.
Example decisions
| Extension | Audience | Choice |
|---|---|---|
| Internal ticket helper | Staff only, Workspace in use | Private, domain publishing if enabled |
| Tool for a customer success pilot | Twenty named customers | Private with a managed Google Group |
| Free community tool | Anyone | Public |
| Beta for a vendor to test | A few testers | Private, trusted testers |
Write the reasoning in your register. Six months later, someone will ask why it was unlisted, and a written answer saves an argument.
Review access lists
Trusted testers and group members are standing permissions. Schedule a quarterly check that each person still needs access, and that the group has an owner who is still with the company.
Quick check
Is an unlisted extension hidden from outsiders?
It is not listed in the store, but anyone who knows the URL can install it. Do not treat it as confidential.
Does private visibility skip review?
No. Per Chrome's documentation, all visibility settings share the same policy requirements and review process.
Sources
Last reviewed: 19 October 2026.
