WordPress Ships Its First Official Browser Extension

The most useful pieces of WordPress tooling I have ever installed were never plugins. They were the small utilities that lived next to the browser: a bookmarklet that stripped the admin bar for screenshots, a keyboard shortcut wrapper that jumped straight to a post’s edit screen from the front end, a devtools snippet a colleague pasted into my address bar in 2013 and I still have somewhere in a text file. None of them ever needed to touch the database. They lived where I was actually working — in the tab.

This week WordPress finally shipped an official version of that utility surface. A browser extension. First party, MIT licensed, no telemetry, in the Chrome Web Store and the Mac App Store, with the source on the WordPress GitHub organization. It is a small announcement with a longer tail than it looks.

My take before the news: this is the class of tool a mature CMS eventually adds because the community keeps rebuilding it independently and the maintenance debt spreads across a hundred private forks. Better to own it in one place, ship it under the project’s name, and let contributors improve it in public. It also happens to be one of the shortest paths from “I manage WordPress sites” to “I have a WordPress-shaped tool in my daily browser chrome” that the project has ever offered.

What is actually new

On August 13, 2026, Jake Goldman announced the WordPress Browser Extension on wordpress.org/news. The extension started as his independent project, is now officially supported by the WordPress project, and lists Fabian Kägy and Khokan Sardar among its contributors. It ships for Chromium-based browsers on the Chrome Web Store (version 1.0.1, 204 KiB, developer listed as the WordPress Foundation) and for Safari on macOS via the Mac App Store. The source code lives at github.com/WordPress/browser-extension under an MIT license.

The feature list, per the announcement post and the repository README, is deliberately narrow:

• Detects WordPress sites automatically via the REST API, generator meta tags, and body classes.
• Hides the admin bar on the front end while preserving its shortcuts in the browser toolbar.
• Gives one-click edit access for posts, pages, and custom post types on the site you are currently viewing.
• Ships a small “My Sites” launcher that stores the list of WordPress installs you are logged into, locally.
• Identifies the host (WP Engine, Kinsta, Pantheon, WordPress.com and others named in the README).
• Bundles a handful of developer tools: block boundary highlighting, a phone-sized preview window, cache-busting reload, and one-click cookie and local-storage clearing for the current site.

Two design choices in the announcement are worth naming explicitly. The privacy line reads “no telemetry, no analytics, no third-party tracking” and the extension only talks to the WordPress site you are currently on — everything else runs locally on your device. And the technical stack, per the README, is the same one WordPress core already uses: React with @wordpress/ui for the popup, @wordpress/scripts for bundling. This is not a side project speaking a different dialect; it is a first-party surface that reads and looks like the rest of the platform.

Context that matters for timing: this landed six days before the WordPress 7.1 GA scheduled for August 19 at WordCamp US Phoenix, per the RC3 post on Make/Core. Whether that was planned or coincidental, the effect is the same — the launch happens against a backdrop of the largest single accessibility ledger a WordPress release has ever published, which quietly makes the admin bar toggle in the extension a small accessibility feature in its own right for anyone who has spent years staring at that fixed 32-pixel strip.

Why it matters for WordPress and WooCommerce people

The narrow feature list is the point. This is not a hosting dashboard, an SEO scanner, or an “AI copilot for WordPress.” It is a small, correctly scoped set of things a person who works with WordPress sites all day would build for themselves if nobody had. Which is exactly why so many of us have small versions of it already, cobbled together from three bookmarks and a keyboard shortcut.

For agencies, three things change on the day this becomes normal:

• Onboarding a new developer is one link shorter. “Install this extension, sign in to the site, you are done” replaces the twenty-minute walkthrough of “here is how our staging URLs work, here is our bookmark folder, here is the SSH alias for the cache flush.”
• Client hand-off screenshots stop showing the admin bar. If you have ever asked a marketing lead to “log out first” before capturing a hero shot, the toolbar toggle removes that step. Same story for accessibility auditors documenting front-end issues.
• The developer tools kill three small in-house plugins. Every agency I know has some variant of a “block outline” mu-plugin, a “cache bypass” query string helper, and a “clear cookies for this domain” browser extension already installed. The official one replaces all three, gets patched by other people, and does not need to be re-added to every fresh laptop.

For WooCommerce specifically, the phone-sized preview and cache-busting reload are the two features I expect to reach for weekly. Testing checkout on a mobile viewport without opening the real DevTools panel, and forcing a fresh load after a theme edit without touching the object cache admin screen, are both boring and both constant. Boring and constant is exactly the shape of work a first-party tool should absorb.

What I would do (or not do) about it

Install it on your own machine this week. That is the whole first step. Sign in on one or two client sites you actually manage, use the admin-bar toggle on the front end for a day, try the phone-preview and cache-buster on a staging environment, and see whether it earns its place next to the tools you already keep in the toolbar. If it does, keep it. If it does not, uninstall it and move on. The project is small enough that you can make that call inside a week.

For the team, add one line to the developer onboarding doc pointing at the Chrome Web Store and Mac App Store links. Do not mandate it. Extensions live in the browser profile and are a personal call in a way plugins on a shared codebase are not. But make it discoverable so the third new hire does not spend an afternoon rebuilding the same admin-bar bookmarklet the second new hire already rebuilt.

Two things I would not do. First, do not install any third-party extension whose pitch is “WordPress toolbar helper” from this week forward — the surface is now owned by the project, the code is public, and the privacy story is auditable. A wrapper on top of a first-party extension is exactly the technical debt this release was meant to retire. Second, do not push the extension out to clients as part of a managed service. It is a developer tool with developer defaults. A shop manager who accidentally toggles the admin bar off and cannot find their way back to the dashboard is a support ticket that did not need to happen.

If you have room for one contribution this quarter and you are already the kind of person who files Trac tickets or opens Gutenberg PRs, the repository at github.com/WordPress/browser-extension is a comfortable place to land. Small surface, MIT license, clean React with @wordpress/ui, and a maintainer list that reads pull requests. Extensions are one of the few places where a well-scoped feature can go from idea to shipping in a couple of weeks rather than a couple of release cycles.

The interesting signal underneath the announcement is not the extension itself. It is that WordPress has finally noticed the toolbar as a first-class surface worth owning — the same way it once noticed themes, and then blocks, and then site editing. Small tools with tight scope, shipped under the project’s name, are exactly the pattern that has kept this platform trustworthy for two decades. This week adds one more.