Can AI Build a Chrome Extension? Yes, With Caveats
AI can generate a working Chrome extension in minutes, but the manifest, permissions model, and store review are still on you.
Yes, AI can build a Chrome extension, and for small, single-purpose ones it can get you most of the way there in an afternoon. The catch is that "the AI writes the code" is maybe 40% of the job. The rest is a manifest file with specific Manifest V3 requirements, a permissions model that Google actively polices, and a store submission process no model can click through for you.
This is the gap that trips people up. Someone asks an AI coding agent for a form-autofill extension, gets a working `content.js` in one prompt, and assumes they're basically done. Then they hit a permissions error in `chrome://extensions`, or their store submission gets rejected for requesting `<all_urls>` when they only touch two pages. None of that is a coding problem. It's a packaging and policy problem, and AI tools generally do not know your extension's actual runtime footprint well enough to get it right without you checking.
If you're new to the broader question of what AI can and can't finish unsupervised, how to build an app with AI covers the same pattern at a larger scale, and it's worth reading alongside this if a browser extension is your first project.
What AI is actually good at here
An AI coding agent can write the JavaScript for a content script, a background service worker, and a popup UI competently. It can scaffold the file structure, wire up message passing between scripts, and generate a first-pass `manifest.json`. For anything that's mostly "read the DOM, transform some text, inject a button," this is genuinely fast, often faster than doing it by hand if you already know extension development.
What it's weaker at is the parts that require knowing Chrome's current policy environment rather than JavaScript syntax: which permission unlocks which API, what triggers a manual review versus an automated one, and how strict the store has gotten about host permissions. Models trained on older documentation will sometimes generate Manifest V2 patterns or request permissions that are technically unnecessary, both of which cause real problems at submission time.
The manifest.json Google now requires
Every extension needs a `manifest.json` declaring its name, version, permissions, and entry points. As of Chrome 138, Google has been removing Manifest V2 extensions from the Chrome Web Store entirely, with a hard removal deadline in August 2026, so anything you build now needs to target Manifest V3 source. MV3 replaced background pages with service workers, changed how content scripts declare their matches, and tightened remote code execution rules. An AI tool that hasn't been told explicitly to target MV3 may still hand you an MV2-shaped manifest, especially older or cheaper models drawing on stale training data.
A minimal MV3 manifest looks like this:
```json
{
"manifest_version": 3,
"name": "Page Text Summarizer",
"version": "1.0.0",
"permissions": ["activeTab", "scripting"],
"action": {
"default_popup": "popup.html"
},
"background": {
"service_worker": "background.js"
}
}
```
The `manifest_version: 3` line, the `service_worker` key instead of a background page, and the specific permission names are things you need to check, not assume the AI got right.
The permissions model, and why it gets extensions rejected
This is the part most feasibility questions skip. Chrome Web Store policy requires extensions to request the narrowest permissions necessary for their actual features, and reviewers explicitly flag broad host permissions like `<all_urls>`, `https://*/*`, or bundling `cookies` and `tabs` together when the extension doesn't need site-wide access source. Requesting more than you use isn't just sloppy, it's the single most common rejection reason, because Google treats broad host access as a data-collection risk regardless of what your code actually does with it.
AI tools tend to over-request by default. If you ask for "an extension that autofills forms," a model may reflexively add `<all_urls>`, `storage`, `cookies`, and `tabs` because that combination shows up constantly in training data for form-related extensions, even when your specific use case only needs `activeTab` and `scripting`. You have to read the generated manifest and cut anything the code doesn't actually call.
Review speed tracks this directly. An extension using only `activeTab` from an established developer account can clear review in under a day. One requesting `<all_urls>` plus `cookies` plus `tabs` from a brand-new account should expect two to four weeks source.
A worked example: page text summarizer
Take a simple, plausible idea: a button in the toolbar that grabs the visible text of the current tab and sends it somewhere to summarize.
Feature | Permission needed | Why |
|---|---|---|
Read the current page's text | `activeTab` | Grants temporary access to the active tab only when the user invokes the extension |
Inject a script to extract text | `scripting` | Required in MV3 to run code in the page context |
Call an external summarization API | `host_permissions` scoped to that one API domain | Never use `<all_urls>` for an outbound API call |
Show results in a popup | `action` with `default_popup` | No special permission, just a UI declaration |
Notice what's absent: no `cookies`, no `storage` unless you're caching past summaries, no broad host access. That's the whole permissions footprint for a functioning tool. A form-autofill helper follows the same logic: `activeTab` and `scripting` to read and fill fields on the current page, `storage` if you're saving field values locally, and host permissions scoped only to the specific sites you support if you're not asking the user to trigger it manually each time.
Packaging, testing, and what AI cannot do for you
Once the code and manifest exist, you load the extension unpacked in `chrome://extensions` with developer mode on, which is where you actually catch manifest errors, missing permissions, and console exceptions an AI can't see from a chat window. This local loop, generate, load unpacked, click around, read the error, fix it, is where most of the real debugging happens, and it's manual by nature.
Publishing is the other piece no model touches. You need a Chrome Web Store developer account, which carries a one-time $5 registration fee covering up to 20 extensions source. You then zip your extension, upload it through the developer dashboard, fill in a privacy practices disclosure that matches your actual permissions, and submit for review. If your permissions and your stated purpose don't line up, expect a rejection with a policy citation you have to address and resubmit against. None of this is something an AI coding agent can execute on your behalf, it happens in Google's dashboard under your account.
This is also where the general limits of AI-generated software show up in a concentrated form. If you want the broader picture of where these tools stop being reliable without human review, limitations of AI app builders is a useful companion read. And if you're weighing an extension against a full mobile app for the same idea, can AI build a mobile app walks through that comparison; extensions are meaningfully cheaper to both build and maintain, partly because they skip an app store's binary review process in favor of a lighter, faster one.
Common questions
Can ChatGPT or Claude write a full Chrome extension by itself?
It can write all the code files, a content script, background worker, popup HTML/JS, and a first-pass manifest. It cannot load the extension, test it in a real browser, or submit it to the Chrome Web Store. Those steps are yours.
Does a Chrome extension built with AI need a backend?
Not necessarily. A summarizer that calls an external API or a form-filler that only reads and writes to the current page can run entirely client-side. If you need to sync data across a user's devices or store user accounts, you'll want one, and the same tradeoffs covered in do I need a backend for my app apply here.
Why do AI-generated extensions get rejected from the Chrome Web Store?
Most commonly, over-broad permissions. AI tools default to requesting `<all_urls>`, `cookies`, or `tabs` even when the extension's actual functionality only needs `activeTab` or a scoped `host_permissions` entry. Trim the manifest to match what the code actually does before submitting.
Is Manifest V2 still an option in 2026?
No. Chrome has been actively removing Manifest V2 extensions from the Web Store, with removal completing by August 2026. Anything built now should target Manifest V3 from the start.
What's the fastest way to test an AI-built extension before publishing?
Load it unpacked. Go to `chrome://extensions`, enable developer mode, and click "Load unpacked" pointing at your extension's folder. This runs it locally without any store submission, and it's where you'll catch most manifest and permission errors.
If you are extending an app you already built, how to add an admin dashboard to an AI-built app covers a similar bolt-on feature.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
