Building a Chrome extension in 2026 is still approachable if you already know basic HTML, CSS, and JavaScript, but the publishing path is stricter than many older tutorials suggest.
The practical sequence is: define one clear browser job, build it with Manifest V3, request the smallest permissions you can, test it as an unpacked extension, package the final files, complete the Chrome Web Store listing and privacy declarations, then submit it for review.
The important part is not just making the code run. A publishable extension also needs a narrow purpose, accurate permissions, compliant data handling, store-ready images, and enough testing that a reviewer can understand what the extension does without guessing.
A publishable Chrome extension in 2026 needs more than working code: keep the purpose narrow, permissions minimal, data handling accurate, store assets current, and the exact release package tested before submission.
What changed from older Chrome extension tutorials?
Older Chrome extension tutorials are useful for the basic idea of going from concept to store submission, but the platform and policy environment have moved on. Manifest V3 is Chrome’s current extension platform. It replaces long-lived background pages with service workers and removes the ability to execute remotely hosted code inside an extension.
Google announced Chrome Web Store policy updates on July 1, 2026, and enforcement began on August 1, 2026. The updated rules tighten the relationship between an extension’s disclosed single purpose and the user data it collects, and require prominent disclosure of data collection. If you are preparing a new extension now, build to those enforced rules before submission rather than treating compliance as a later cleanup.
Review timing is another practical difference. Google currently warns that a surge in submissions has caused extended Chrome Web Store review times since April 2026. Its review guidance says most extensions are reviewed within a few days, but some can take a few weeks.
1. Start with one narrow browser job
A good first extension should be easy to explain in one sentence. That matters for product clarity, permission design, and Chrome Web Store review. For this walkthrough, the example extension is Page Marker: when the user clicks the extension icon, it adds or removes a temporary outline around the current web page.
That example is intentionally small. It does not collect data, make network requests, store browsing history, or request permanent access to every site. It is enough to demonstrate Manifest V3, an action, a service worker, activeTab, chrome.scripting, local testing, and packaging.
2. Create the project files
Create a folder named page-marker. Put manifest.json and service-worker.js in the root. Add a 128×128 PNG icon before you prepare the store package.
manifest.json
{
"manifest_version": 3,
"name": "Page Marker",
"version": "1.0.0",
"description": "Adds a temporary outline to the current page when you click the extension.",
"permissions": ["activeTab", "scripting"],
"background": {
"service_worker": "service-worker.js"
},
"action": {
"default_title": "Mark this page"
},
"icons": {
"128": "icon128.png"
}
}
The manifest is the extension’s contract with Chrome. It identifies the extension, declares Manifest V3, registers the service worker, defines the toolbar action, and requests the permissions needed by the feature.
Why use activeTab instead of broad host access?
The activeTab permission gives temporary access to the current tab after an explicit user gesture, such as clicking the extension action. For a feature that only needs to act on the page the user deliberately invokes, that is a better fit than requesting persistent access to every website. Chrome’s guidance recommends minimizing permissions and using optional or narrower permissions when the feature allows it.
Official Chrome for Developers activeTab tutorial screenshot. Google / Chrome for Developers; page content CC BY 4.0 except where otherwise noted.
3. Add the service worker
service-worker.js
chrome.action.onClicked.addListener(async (tab) => {
if (!tab.id) return;
try {
await chrome.scripting.executeScript({
target: { tabId: tab.id },
func: togglePageMarker
});
} catch (error) {
console.error("Page Marker could not run on this page:", error);
}
});
function togglePageMarker() {
const id = "__page_marker__";
const existing = document.getElementById(id);
if (existing) {
existing.remove();
return;
}
const marker = document.createElement("div");
marker.id = id;
Object.assign(marker.style, {
position: "fixed",
inset: "0",
border: "4px solid #ffb000",
pointerEvents: "none",
zIndex: "2147483647",
boxSizing: "border-box"
});
document.documentElement.appendChild(marker);
}
Testing note: The sample manifest and service worker were syntax-checked. This package does not claim an end-to-end Chrome runtime test; load the exact folder in Chrome and test it on permitted web pages before submission.
The service worker waits for a click on the extension action, then asks chrome.scripting to run a small function in the active tab. The code catches execution failures because Chrome-internal and other restricted pages are not appropriate targets for normal page injection.
Original editorial diagram based on Chrome Extensions activeTab and scripting documentation.
4. Load the extension locally
Open chrome://extensions, enable Developer mode, choose Load unpacked, and select the page-marker folder. The extension should appear in the Extensions page and in the browser’s extensions menu.
Run a basic smoke test before you add more features:
- Open a normal HTTPS page.
- Click the Page Marker extension action.
- Confirm the outline appears.
- Click again and confirm the outline disappears.
- Open the extension’s service-worker inspection view and confirm there are no unexpected errors.
When you change the manifest, service worker, or other extension components, reload the extension from chrome://extensions before retesting. A browser extension can look correct in the file system while Chrome is still running the previous loaded version.
Test the exact release folder you plan to zip and submit, not just your working development copy. That catches missing assets, stale files, permission changes, and packaging mistakes before review.
5. Treat permissions as part of the product design
Permission choices affect user trust and review complexity. Chrome separates API permissions, host permissions, optional permissions, and content-script match patterns. Some permissions trigger install-time warnings, and broad host access can lead to more scrutiny.
For Page Marker, activeTab plus scripting is enough. If a future version genuinely needs persistent access to a set of websites, request only those hosts. If access is needed only after the user chooses a feature, consider optional permissions. Do not add powerful permissions “just in case.”
Chrome’s review documentation specifically lists broad host permissions, sensitive execution permissions, large amounts of code, and hard-to-review code as factors that can increase review time.
6. Check the privacy and remote-code rules before packaging
Manifest V3 does not allow an extension to load and execute remotely hosted code. Keep executable extension code inside the reviewed package. Remote services can still provide data when your feature needs them, but do not design the extension so downloaded JavaScript becomes executable extension logic.
In the Chrome Web Store Privacy tab, you must state the extension’s single purpose, justify its permissions, declare data use, and answer the remote-code questions accurately. If the extension handles user data, its privacy policy and in-product disclosures must match what the extension actually does.
The July 2026 policy update makes this especially important. Since August 1, user data collected by an extension must be necessary for its disclosed single purpose, and data collection must be prominently disclosed. Google also says developers must proactively disclose changes to data-handling practices after installation.
7. Prepare a clean release ZIP
Before uploading, make a release copy of the project and remove development-only files, secrets, test fixtures, source maps you do not intend to distribute, and anything the extension does not need. Make sure manifest.json is at the root of the ZIP rather than inside an extra parent folder.
A minimal release package for this example contains:
- manifest.json
- service-worker.js
- icon128.png
Increment the version in manifest.json every time you submit a new extension version. Test the exact release folder as an unpacked extension before you zip it.
8. Register and complete the Chrome Web Store developer account
Before you can publish, register as a Chrome Web Store developer, agree to the developer terms, and pay the one-time registration fee shown during signup. Use an email address you actively monitor because review, rejection, policy, and takedown notices are sent to the publisher account.
Complete the developer profile before the first submission. The store also requires account and listing information that reviewers and users can rely on, so avoid placeholder contact details or metadata you do not intend to maintain.
9. Build the store listing before you upload
A technically working ZIP is only part of the submission. Google’s official Chrome Web Store documentation currently conflicts on one listing asset: the dedicated image-guidelines page says the mandatory assets are the 128×128 PNG extension icon, a 440×280 small promotional image, and at least one screenshot, while an older Store Listing page still says a YouTube promotional video is required.
Because both pages remain live, verify the promotional-video field in the current Developer Dashboard at submission time rather than treating either documentation page as complete on its own. Screenshot guidance remains 1280×800 or 640×400.
Use screenshots that show the actual extension experience. Do not fill the listing with decorative screenshots, unreadable text, or capabilities the extension does not have. The listing description, screenshots, category, privacy fields, and actual behavior should tell the same story.
Chrome Web Store policy says blank or missing listing elements such as descriptions, icons, or screenshots can lead to rejection, and misleading or out-of-date metadata is not allowed.
10. Upload, complete the dashboard tabs, and submit
In the Chrome Developer Dashboard, add a new item and upload the ZIP. After Chrome accepts the package, complete the Store Listing, Privacy, Distribution, and Test instructions sections as applicable. The Privacy section is where you explain the single purpose, justify permissions, disclose data use, and provide a privacy-policy link when required.
Original editorial workflow diagram based on Chrome Web Store publishing documentation.
Then choose Submit for Review. If you do not want the item to go live immediately after approval, use deferred publishing. Chrome’s current documentation says an approved staged submission can remain unpublished for up to 30 days before it reverts to draft and must be submitted again.
11. Plan for review time instead of promising a launch date
Do not schedule a marketing launch around an assumed same-day approval. Chrome says most reviews finish within a few days, but some can take a few weeks, and it is currently warning of extended times because of the 2026 submission surge.
New developers, new extensions, broad host permissions, sensitive permissions, major code changes, and hard-to-review code may receive closer scrutiny.
If a submission has been pending for more than three weeks, Chrome’s review guidance says to contact developer support. If the extension is rejected, fix the cited policy issue rather than repeatedly resubmitting the same package.
12. Update the extension without creating review problems
For an update, raise the manifest version, test the exact new package, upload the complete ZIP, update any changed listing or privacy disclosures, and submit the new version for review. Treat permissions and data practices as release-level changes, not implementation details.
If you add a new permission, new host access, new data collection, or a new remote service, revisit the user-facing explanation and the Chrome Web Store privacy fields before submitting. An extension can be technically correct and still fail review because the declared purpose, permissions, or data disclosures no longer match the product.
A practical pre-submission checklist
- The extension has one clear, defensible purpose.
- manifest_version is 3.
- Only necessary permissions and host access are requested.
- The exact release build works when loaded unpacked.
- No secrets or remotely hosted executable code are included.
- The 128×128 icon, 440×280 promo image, and at least one valid screenshot are ready; verify the current Developer Dashboard’s promotional-video field before submission.
- Store listing text matches the extension’s actual behavior.
- Privacy disclosures and any privacy policy match the real data flow.
- The ZIP has manifest.json at its root and the version is correct.
- You have allowed enough time for review before announcing a launch date.
The shortest path to a publishable first extension
The fastest route is not to start with a complicated extension. Start with a narrow feature, build it on Manifest V3, use the smallest permissions that make the feature work, and test the exact package you intend to submit. Then treat the Chrome Web Store listing and privacy declarations as part of the product rather than paperwork at the end.
That approach makes the first build easier to debug and the first review easier to understand. Once you have successfully shipped a small extension, adding storage, content scripts, messaging, options pages, or external APIs becomes much easier because you already understand the platform’s permission and publishing boundaries.
