The WordPress Browser Extension: What It Does and What You Are Granting

WordPress now has an official browser extension. It was announced on August 13, 2026 by Jake Goldman on the WordPress.org news blog, and it is available in the Chrome Web Store for Chrome and Chromium browsers and in the Mac App Store for Safari on macOS, published under the WordPress Foundation account. It is open source under an MIT licence, and the code lives in the WordPress GitHub organisation.

The announcement post explains what it does. This article is about the part the announcement does not cover: whether the WordPress browser extension is worth the toolbar slot, which of its features change how your day goes and which ones duplicate tools you already have, and, most importantly for anyone who signs into other people's sites for a living, exactly what access you hand over when you click install.

TL;DR

• The extension moves admin bar shortcuts into the browser toolbar, so you can hide the admin bar on the front end and keep quick access to the editor and dashboard.
• The two features that change daily work most are the site launcher, if you manage several sites, and the cache-bypass reload, if you debug "it still looks the same to the client" problems.
• It requests storage, scripting and cookies plus host permissions for every http and https page. Chrome will describe that as reading and changing data on all sites, and that description is accurate.
• The trade is justified in the project's SECURITY.md, which documents each permission and the alternative that was tested and rejected. No telemetry, no analytics, no remote servers, no remote code.
• It is a convenience layer, not a management tool. It does not update plugins, take backups, or monitor anything.
• Chrome, Chromium browsers and Safari on macOS only at launch. Firefox and Edge listings are described as post-1.0 work, not commitments.

What the WordPress browser extension is

It is a toolbar extension that recognises WordPress sites as you browse and puts site management shortcuts in the browser rather than in the page. The toolbar icon carries three states: not WordPress, WordPress, and WordPress with you signed in. Detection uses signals the page already exposes, including REST API links, the generator tag, asset paths and body classes, so nothing has to be installed on the site itself.

The project started as Goldman's personal side project, wp-detective, moved into the WordPress GitHub organisation, and became an official project with Matt Mullenweg's backing. Fabian Kägy, a core contributor, is a co-maintainer, and Khokan Sardar contributed patches. Both maintainers work at Fueled, formerly 10up. That provenance matters more than it might sound, and the permissions section below explains why.

At the time of writing the Chrome Web Store lists version 1.0.1, updated August 13, 2026, at roughly 204 KiB, offered by the WordPress Foundation. Version numbers move; check the store listing rather than this article if the exact build matters to you.

The roadmap file that describes those plans opens by calling itself a working draft rather than a commitment, so treat the Firefox and Edge lines as direction, not a delivery date.

Why the admin bar was the starting point

The admin bar is useful and it is also permanently in the way. It sits inside the viewport, which means the page you are looking at while signed in is never quite the page a visitor sees. On anything using a sticky header, a 100vh layout, or scroll-driven effects, the offset introduces artefacts, and you can lose twenty minutes chasing a bug that only exists because you are logged in.

The standard fix has always been to turn the bar off in your profile, or filter it off in code:

add_filter( 'show_admin_bar', '__return_false' );

That solves the visual problem and creates a workflow one. The shortcuts leave with the bar, so getting to the editor for the page in front of you becomes a trip to the dashboard, a search, and a click. The other workarounds cost something too: a second browser profile means signing in twice, and a private window means signing in every time.

The extension separates those two things. The bar can be hidden per site or hidden everywhere by default, with per-site choices overriding the default, and the shortcuts move to the toolbar where they do not take up page space. The hide runs at document_start specifically so the bar does not flash before it disappears, which is the difference between a feature you keep on and one you switch off after a week of flicker. Bringing the full bar back is two clicks and no dashboard visit.

If your site disables the admin bar in code rather than in user settings, the extension surfaces a hint saying so rather than silently failing. That is a small detail, and it is the kind of thing that separates a tool built by people who support sites from one built to demo well.

Jumping between sites without a bookmarks folder

The extension keeps a locally stored launcher of WordPress sites you have signed into, so they stay one click away from anywhere. This is the feature that earns the extension its place for anyone running more than a handful of sites.

Be honest about the size of the win. It replaces a bookmarks folder, or typing a domain and appending /wp-admin, or a spreadsheet of client URLs. Each individual saving is a few seconds. The reason it adds up is frequency: an agency developer switching contexts a dozen times a day is doing that lookup a dozen times a day, and doing it while already thinking about something else.

The list is stored on your device in chrome.storage.local. It is not synced across browsers, and it is not backed up anywhere. If you wipe extension data or move machines, you rebuild it by signing in to the sites again. For a convenience feature that is fine, but do not treat it as an inventory of client sites. Your actual source of truth for that stays wherever it already is.

The editing shortcuts you will actually use

Opening the popup on a site you manage gives you the editor for exactly what you are looking at: posts, pages, categories, tags, author archives and custom post types, including hyphenated CPT slugs. On block themes, template-backed pages open in the Site Editor rather than dropping you somewhere generic. There is a keyboard shortcut, Alt+Shift+E (Option+Shift+E on macOS), and Chrome lets you rebind it at chrome://extensions/shortcuts.

The reverse direction works too. On a wp-admin edit screen, the popup offers the published page or a nonce-carrying preview of a draft, which saves the usual scroll to find the preview button. A "+ New" menu mirrors the admin bar's version, limited to the post types your role can actually create, and there is a one-click sign out that uses the admin bar's own nonce so WordPress skips its confirmation screen.

None of this is new capability. All of it exists in the admin bar already. The point is that it exists in the toolbar instead, which is what makes hiding the admin bar cost nothing.

Which developer tools earn their place

The extension bundles five tools for developers and testers. They are not equally useful, and listing them as a flat feature list, which most coverage does, is not helpful. Here is the honest ranking.

The two at the top are the ones that genuinely save steps, and they save them in the same scenario: a change is live, you can see it, the client cannot, and you need to work out whether the problem is a page cache, an edge cache, a service worker, or a stale cookie. Being able to bypass the cache and clear site data without losing your admin session shortens that loop.

The clear-data tool is more careful than the browser's own version. It removes the current site's host-only cookies while deliberately sparing WordPress authentication cookies and parent-domain cookies, so you do not sign yourself out of sibling subdomains as a side effect. That is a considered piece of behaviour, and it is the kind of thing a generic "clear cookies" extension gets wrong.

Highlight Blocks and mobile preview overlap with tools you already have. Keep them; just do not install the extension for them.

Host detection and the Site Information panel

The extension identifies the managed WordPress platform behind a site where the signals allow it, with a documented list covering WP Engine, WordPress VIP, Pantheon, Kinsta, Flywheel, Cloudways, WordPress.com, Pressable and local development environments. Results are cached per origin locally.

Understand what this is before you rely on it. It is signature matching against a maintained list, not a universal fingerprinting service. A host that is not on the list, or one sitting behind a CDN or reverse proxy that strips the identifying signals, will simply show nothing. That is an absence of a signature, not evidence about the host. The project's roadmap describes ongoing host-detection additions as managed platforms ship new signatures, which is the correct way to run a feature like this: a list that grows rather than a guess that gets confidently wrong.

For sites where you are signed in as an administrator, an optional Site Information panel surfaces the active theme with its version and author, and the installed plugins as pills with versions on hover, sourced from the site's own REST API with a DOM-scanned fallback. The panel is marked experimental in the extension's settings, so treat what it reports as a convenience rather than an audit. If you need an authoritative plugin and version inventory, WP-CLI on the server is still the answer:

wp plugin list --fields=name,status,version,update

One security note worth internalising: the theme and plugin information the panel reads is, for the most part, information any visitor can infer from a WordPress site's public output. The extension is not exposing something that was previously hidden. It is making visible how much a WordPress site tells the world about itself by default, which is a useful reminder when you are deciding what to keep patched.

What you are granting when you install it

This is the section that matters, and it is worth being precise rather than reassuring.

The permissions, and what each one powers

The repository manifest requests four API permissions plus host permissions for every http and https URL. The project documents the rationale for each in its SECURITY.md, which is unusual and which is exactly what you want to see.

Why it asks for access to every site

Chrome will present the host permissions in its own language, something close to reading and changing all your data on all websites. That description is accurate and you should not talk yourself out of taking it seriously.

The reason for it is structural rather than lazy. The extension's core behaviour is ambient: the toolbar icon reflects WordPress and sign-in state for whatever page you are on, without you clicking anything. An icon that only tells you something after you click it defeats the purpose of the icon. That requires content scripts on all pages. So does hiding the admin bar before first paint, since a script that runs later produces exactly the flash it is meant to prevent.

The maintainers say a gesture-scoped alternative using activeTab alone was built and evaluated, and that it removed ambient detection entirely and broke detection in the Safari build. They kept the broad permission and wrote down why. That is a defensible answer. It is not the same as a harmless one.

What limits the risk is what the code does with the access, and here the documented behaviour is narrow: local DOM inspection for WordPress signals, page-local DOM changes only for features you enable, and same-origin REST requests only to the site you are already viewing. Nothing about page content, browsing history or detection results is transmitted off the device, because there is nowhere for it to go. The extension has no servers, no developer accounts, and no analytics. The Chrome Web Store listing carries the matching declaration that the developer does not collect user data.

The four questions to ask before installing any extension

Here is the durable part, because you will install other extensions this year and most will not be this well governed. A browser extension that can see your pages and your cookies is, in practical terms, sitting inside every admin session you open. Before you install one, ask:

• Who publishes it? A named organisation with a real address and a working contact, not an individual developer account with a generic name. Publisher changes are the classic attack: a popular extension gets sold, and the new owner ships an update to an install base that already trusted the old one.
• What permissions does it request, and is there a reason? Broad host access is not automatically disqualifying. Broad host access with no explanation, for a tool that only needs to run on one site, is.
• Is the source public? Not because everyone reads it, but because the possibility that someone will changes what ships. A public repository also means you can see whether the shipped build matches, and whether anyone has raised concerns.
• Does it phone home? Look for a stated position on telemetry, and for a privacy declaration in the store listing that matches it. "We collect anonymous usage data" from an extension with access to every page you visit is a bigger statement than it looks.

The WordPress extension answers all four well: WordPress Foundation as publisher, per-permission rationale in a public security policy, MIT-licensed source in the WordPress GitHub organisation, and a documented no-telemetry position with a private vulnerability reporting channel and a stated five business day acknowledgement target.

Important: For agency and freelance work, the sensible practice is not "avoid extensions" but "separate profiles." Keep the browser profile you use for client wp-admin sessions clean, with a small number of vetted extensions, and do your general browsing and experimenting somewhere else. That way a bad extension you installed for one afternoon never had a session to steal.

What it does not do

It is a convenience layer, not a control panel, and it never claims otherwise. It does not update plugins, run backups, monitor uptime, scan for malware, or manage anything across sites. If you arrived expecting a management dashboard in your toolbar, this is not that, and no amount of using it will make it that.

Availability is genuinely limited at launch. Chrome and Chromium browsers, plus Safari on macOS. No Firefox or Edge listing yet, and Safari means macOS, not iOS or iPadOS. Mobile browsers are listed as out of scope for now on the grounds that WebExtension support is patchy there, which is a fair reading of the situation.

Multi-account and profile switching are also out of scope at 1.0. The extension uses whatever WordPress login the current browser session has. If you routinely hold two WordPress identities at once, browser profiles remain your tool for that, not this.

The Site Information panel is marked experimental, and host detection covers a specific list of platforms rather than every host. Neither is a defect; both are worth knowing before you build a habit on top of them.

Should you install it?

The general case is straightforward. If your work involves being signed into WordPress on more than a couple of sites, the extension removes small frictions that recur many times a day, and it does so with better governance than almost anything else you could install for the same purpose. If you touch one site occasionally, the case is weak and there is no reason to force it.

Frequently asked questions

Is the WordPress browser extension free?

Yes. It is free and open source, released under the MIT licence, with the code in the WordPress GitHub organisation. There is no paid tier, no account to create, and no service behind it to subscribe to. It is published in the Chrome Web Store and the Mac App Store under the WordPress Foundation publisher account.

Does it work in Firefox or Edge?

Not at launch. The 1.0 release covers Chrome and Chromium-based browsers through the Chrome Web Store, and Safari on macOS through the Mac App Store. The project's roadmap lists Firefox Add-ons and Edge Add-ons as post-1.0 work, with a note that the Firefox build needs a WebExtension compatibility audit first because Firefox's extension surface diverges from Chromium in places. That roadmap describes itself as a working draft rather than a commitment, so there is no published date.

Does the extension track my browsing?

No. The project states plainly that there is no telemetry, no analytics and no third-party tracking, and the Chrome Web Store listing carries a matching declaration that the developer does not collect user data. Preferences, your site list and the detection cache are stored locally on your device. The only network requests it makes on your behalf go to the WordPress site you are already viewing, using that site's own REST API.

Do I need to install a plugin on my site for it to work?

No, and that is one of its better properties. Detection works from signals a WordPress site already exposes: REST API links, the generator tag, asset paths and body classes. The editing shortcuts use your existing WordPress session and the site's own endpoints. Nothing is installed server-side, so the same tools are available on every WordPress site you visit, including ones you do not control.

Why does it ask for access to all websites?

Because it has to detect WordPress on any site you visit, without you clicking first, and because hiding the admin bar before the page paints requires a script that runs at document start. The maintainers documented that they built and tested a narrower version scoped to user gestures, and that it removed the ambient detection entirely and broke the Safari build. The rationale for each permission is published in the project's security policy, which is worth reading if the access concerns you.

Is it safe to use on client sites?

The governance is about as good as browser extensions get: named foundation publisher, public MIT-licensed source, documented permission rationale, a private vulnerability reporting process, and no remote code or servers. That said, any extension with broad host access is inside your admin sessions, so the sensible precaution is structural rather than specific to this tool. Keep client work in a browser profile with a short, vetted extension list, and do everything else somewhere else.

Does it replace a WordPress management dashboard?

No. It has no update management, no backups, no monitoring, no security scanning and no cross-site actions. It is a shortcut layer over sites you already sign into individually. Anything involving running the sites rather than reaching them still belongs to your host's dashboard, WP-CLI, or whatever management tooling you already use.

Can I still use it on sites I do not manage?

Yes, with reduced function. On any WordPress site, the toolbar icon tells you it is WordPress and, where the signals allow, which managed platform it is on. The developer tools that do not require a session, like the cache-bypass reload and the block outlines, work on the rendered page. Editing shortcuts and the Site Information panel need a signed-in session with the right capabilities.

Conclusion

The WordPress browser extension is a small tool with a clear purpose, and the honest summary is that it removes a set of frictions you have probably stopped noticing. Hiding the admin bar without losing the shortcuts, jumping between sites without a bookmarks folder, and bypassing a cache without signing yourself out are not headline features. They are the things you do dozens of times a day, and shaving each one is worth more than it sounds.

What makes it worth recommending rather than just describing is the governance around it. A foundation publisher, public source, a written rationale for every permission it requests, and a documented no-telemetry position is a higher standard than most of what sits in your toolbar. Use that as your bar for the next extension someone recommends, and be as sceptical of the ones that cannot meet it.

The one thing to hold on to: it is a convenience layer over sites you already manage, not a way to manage them. The work of keeping those sites patched, backed up and recoverable happens somewhere else. If that side is currently manual, MagicWP's managed WordPress hosting handles daily off-site backups with one-click restore, automatic core updates with rollback, and one-click staging from the same dashboard, with Magic Login for getting into wp-admin without a password prompt. The extension makes the last few clicks faster. The platform underneath is what decides whether a bad update is a ten-minute annoyance or a bad afternoon.