stable-diffusion-webui-extensions: the index behind the extension list

index.json is the entire product surface

There is no code to install here. The README states that the Stable Diffusion web UI accesses index.json from this repository to show users the list of available extensions. That single file is the deliverable, and the rest of the tree exists to produce it. The top level shows the pieces: extension_template.json as the shape a new entry must take, extensions as the directory where submitted entries live, index.json as the assembled output, tags.json holding the tag vocabulary, removed as the holding area for withdrawn entries, and .github holding the automation that assembles the output. The primary language is not even recorded for the repository, which is a hint about its nature: this is a data set with a review process wrapped around it, not a program. If you are looking for a way to extend the web UI, this is the wrong repository, because the extension code lives in its own project. If you want to be listed, this is exactly the right place.

Submitting an extension means adding one JSON entry

The submission path has five steps, and none of them involve shipping code. Fork the repository, make a copy of extension_template.json, fill in that copy and rename it appropriately, move it into the extensions directory, then open a pull request and wait for review. What you write is a description of an extension that already lives somewhere else. Two constraints shape the diff. The documentation says not to edit index.json directly, since that file is generated, and not to modify any other files unless there is a special reason, so a pull request that touches the assembled output or the workflow will be rejected on process grounds rather than content. There is also a small courtesy rule that has a practical effect: you can submit an extension you did not write, but it is preferred that the author does it themselves. Review is not automatic. The notes say not all extensions will be accepted and that the extension will be reviewed and assessed, and the first note is the strictest: an extension has to be functioning to be included.

Pull requests target extensions, GitHub Actions builds master

The branching arrangement is unusual enough to trip people up. The default branch of the repository is extensions, and pull requests from contributors target that branch. After a merge, the entries are automatically assembled and deployed to the master branch using GitHub Actions. So the branch you fork from and open the pull request against is not the branch the web UI reads. The web UI fetches index.json, and the assembled result lives on master, while master is not the branch contributors work in. Two consequences follow. First, the history a reviewer sees is the branch history of individual entries, not the history of the generated file, which keeps the diff readable. Second, there is a short delay between a merge and the assembled output, and the added date is populated automatically after merge rather than being written by the contributor. If you are checking whether your entry is live, look at the timestamp on master and not at the merge commit on extensions.

tags.json encodes two obligations and two categories

The tag vocabulary is defined in tags.json, and two of the tags are requirements rather than descriptions. The online tag is required for any extension that connects to an external server during regular use, with the exception of a one time download of assets. The ads tag is required for any extension that contains advertisements or self-advertisement inside the extension itself. That is a narrow definition on both counts, and it is worth reading closely: a one time asset download does not trigger the online requirement, while self-promotion inside the extension does trigger the ads requirement, which is a distinction most submitters assume in the other direction. Two further tags are categorical. The localization tag is for localization files only and explicitly not for extensions that add localization functionality such as a translator. The installed tag is used internally by the web UI and is not meant for categorisation, so using it in a submitted entry would be a mistake that communicates nothing to a user filtering the list.

Stale entries get redirected to a fork or dropped into removed/

The index is a living catalogue, and the documentation explains how it shrinks. If an extension is no longer functional, or is no longer maintained, the maintainers might redirect it to a fork or remove it from the index. The word might is doing real work there: neither outcome is guaranteed, and the decision sits with the people running the repository. The removed directory at the top level is where that history is kept, separate from the active index, so entries withdrawn from the list remain traceable while no longer appearing in it. Removal is not only a maintainer action. The notes say that if you want your extension removed, or you believe the description does not properly describe it, you can open an issue or a pull request. The same submission route serves both directions, which is a sensible design for a catalogue that people depend on for discovery.

No releases, no stated licence, and a push on 2026-10-20

Two pieces of project metadata deserve a second look before you build a process on top of this repository. There are no GitHub releases, so the catalogue has no versioned history to pin against, and the extension list the web UI shows moves whenever master is rebuilt. The licence field is also not stated, which matters if you plan to mirror the list into your own tooling or redistribute it, because the terms under which index.json and the extension entries can be reused are not documented here. The repository is not archived and the last push was on 2026-10-22, so the entries are still being worked on, and the process itself is described well enough in the README that a new contributor can follow it without asking questions. The practical upgrade path is the pull request workflow itself: a new entry, a merge into extensions, and an automatic rebuild of master.

An alternative to the index is reading extensions/ yourself

If your only need is to discover extensions rather than to publish one, the index is not strictly required. The same information sits in the extensions directory as individual JSON entries, and browsing that directory gives you the same set of descriptions without the assembled file, the tags applied to the UI filters, or the removal history that the index and the removed directory keep side by side. The difference is integration. The web UI reads index.json, so an entry in this repository is what puts an extension in front of users of that interface, and it brings the review that decides whether an entry is functioning and correctly tagged. Writing your own scraper over extensions/ gives you a catalogue without the distribution channel and without the labels, which is fine for a personal list and wrong for anything that has to stay in sync with what users actually see.

Editorial conclusion

Use this repository when you want your extension listed in the web UI extension browser, and follow the extension_template.json entry and pull request route exactly. Do not treat it as a software dependency, since it publishes no releases and states no licence, and check the online and ads tag obligations before you submit an entry.

Frequently asked questions

Official sources

1. AUTOMATIC1111/stable-diffusion-webui-extensions on GitHub
2. Issues
3. README