Extension icons and manifest declarations

​

Template example

​

action

npx extension@latest create my-extension --template=action

pnpx extension@latest create my-extension --template=action

yarn dlx extension@latest create my-extension --template=action

bunx extension@latest create my-extension --template=action

deno run -A npm:extension@latest create my-extension --template=action

​

Icon capabilities

​

Supported icon fields

​

Sample icon declaration in manifest.json

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "icons": {
    "16": "icons/icon-16.png",
    "48": "icons/icon-48.png",
    "128": "icons/icon-128.png"
  },
  "action": {
    "default_icon": "icons/action-icon.png"
  }
}

​

Generate PNG sizes from an SVG

for size in 16 32 48 128; do rsvg-convert -w $size -h $size icon.svg -o icons/icon-$size.png; done

​

Output path

<path-relative-to-manifest>            # icons keep their source location
browser_action/<theme-icon-filename>   # for theme_icons

​

Path behavior

• Extension.js resolves relative icon paths from the manifest folder.
• Leading / and public/... resolve to extension public-root semantics.
• Extension.js can watch public-folder assets without re-emitting them through the icon feature itself.

​

Development behavior

• Changing existing icon files triggers recompilation.
• Changing manifest icon entrypoint references can require restarting the dev server.
• Missing required icon files produce build errors (some optional icon groups can warn instead).

​

Best practices

• Declare manifest icon fields explicitly instead of relying on incidental asset imports.
• Provide multiple icon sizes (16, 32, 48, 128) for sharper UI across browser surfaces.
• Keep icon filenames stable to reduce manifest churn during development.
• Use public-root paths intentionally and test resulting manifest output paths.

​

Next steps

• Continue with web-accessible resources.
• Learn more about Special folders.