> ## Documentation Index
> Fetch the complete documentation index at: https://extension.js.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Store metadata in one STORE.md file

> Keep listing copy, permission justifications, privacy disclosures, and reviewer notes for Chrome, Firefox, and Edge in one tracked STORE.md file.

A cross-browser extension submits to several stores, and every store asks for the same paperwork: listing copy, permission justifications, privacy disclosures, reviewer notes, and release notes. The `STORE.md` convention puts all of it in one tracked file at the project root, so a resubmission never reinvents it.

The file has a second job. Deployment tooling that supports the convention reads it at submission time and attaches the fields each store API accepts. Everything else stays a copy-paste reference for the store dashboards.

## When to create it

Author `STORE.md` before the first submission, at the moment publishing intent appears. Submission tooling reads the file silently: when it is missing, submissions go out without reviewer notes, release notes, or certification notes, and nothing warns you. The file earns its keep by being maintained while the code changes, not written in a scramble at the end. For the full submission journey around it, see [Publish to the browser stores](/docs/publishing).

## Structure

One `##` section per store, with shared material above the store sections. Store sections match by heading text, so `## Firefox Add-ons`, `## firefox-amo`, and `## AMO` all work. The same applies to Chrome and Edge.

```markdown theme={null}
# Store metadata

Last updated: 2026-07-20

## Listing

Name, one-line summary, long description, category, screenshot list.
Write user benefits, not implementation.

## Privacy and data use

What is collected, stored, or transmitted, and the privacy policy URL.
This section must match what the code does and what the manifest's
Firefox data_collection_permissions key declares.

## Chrome Web Store

### Permissions justification

- tabs: reads the current tab URL to show per-site settings.
- storage: persists user preferences locally.

### Single purpose

One sentence that states the extension's single purpose.

## Firefox Add-ons

### Reviewer notes

Test credentials and the steps a reviewer needs to exercise the
extension. Include build-from-source instructions when the upload
is bundled; AMO requires a source zip in that case.

### Release notes

User-facing notes for this version.

## Edge Add-ons

### Certification notes

Anything the certification team needs to test the extension.

## Version history

- 1.2.0 (2026-07-20): added per-site settings. Submitted to all stores.
- 1.1.0 (2026-07-01): rejected on AMO for a vague tabs justification.
  Fixed by naming the exact data the extension reads.
```

## What each store reads

The Firefox and Edge submission APIs accept reviewer-facing notes, so tooling that supports `STORE.md` can send them for you:

| Store section | `###` field | Sent as |
| - | - | - |
| Firefox | Reviewer notes | AMO `approval_notes` |
| Firefox | Release notes | AMO `release_notes` |
| Edge | Certification notes | Edge submission `notes` |

The Chrome Web Store accepts no listing metadata over its API, so the whole Chrome section is a reference for the developer dashboard. Its shape mirrors the sections agent tooling expects from a `CHROMEWEBSTORE.md` file, so an agent that looks for those sections finds them here.

## Starter files in the templates

Every Extension.js template ships a starter `STORE.md` generated from its own manifest. The permission justifications already match the permissions the template requests, and the placeholder lines are marked `TODO`. Create a project from a template and the convention is in place from the first commit:

```bash theme={null}
npx extension@latest create my-extension --template react
```

## Keep it current

Update `STORE.md` in the same change that makes it stale:

* **Manifest changed** (`permissions`, `host_permissions`, `content_scripts`): revisit every justification. Each permission needs a specific, plain-English reason. "Needed for the extension to work" fails review on every store.
* **User-facing behavior changed**: refresh the listing copy and bump the last-updated date.
* **New release**: add a version history entry and rewrite the release notes.
* **Data handling changed**: update the privacy section, the policy it links to, and the manifest's Firefox `data_collection_permissions` declaration together. The three must agree. See [Firefox store readiness](/docs/features/multi-platform-builds#firefox-store-readiness-data-collection-permissions) for the mandatory manifest key.
* **Store rejection**: record the reason and the fix in version history, so the next submission does not repeat it.

## Hygiene

* Track the file in git. It is part of the project, not a scratch note.
* Keep it out of the extension zip. The production build packages only `dist/<browser>/`, so a root-level `STORE.md` never ships to users.
* Never put real user credentials in it. Reviewer test accounts are throwaway by construction.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.