Fu-Jie/openwebui-extensions: A Personal Plugin Collection for Open WebUI
A collection of enhancements, plugins, and prompts for Open WebUI, developed and curated for personal use to extend functionality and improve experience.
At a glance
- What is it?
- The repository bundles filters, pipes and tools that add mind maps, Excel and Word export, infographics and context compression to Open WebUI. It is an MIT-licensed personal collection, not a supported framework, and the README is explicit about that.
- Who is it for?
- Adopt this collection if you already run Open WebUI and want export, visualisation or context-management plugins that you can read in full before installing, and if you are comfortable tracking the release tags for fixes. Do not adopt it as a dependency for a product or for a multi-tenant deployment where an unmaintained plugin becomes an incident.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the collection adds to an Open WebUI instance
Open WebUI ships as a self-hosted chat interface, and its extension surface is deliberately narrow: filters, pipes and tools that you load into the running instance. This repository is a collection of those extensions, written in Python and curated by one author. The README describes it as "developed and curated for personal use to extend functionality and improve experience", which is the most important sentence in the project. It sets the expectation: these are plugins one person built for their own deployment and then published.
The named plugins cover a specific set of gaps. Smart Mind Map turns text into a mind map. Smart Infographic produces an infographic. Export to Excel and Export to Word Enhanced take conversation content out of the chat and into office formats, with Chinese-language variants (导出为 Excel, 导出为Word增强版) published alongside the English ones. Async Context Compression addresses the context window problem by compressing conversation history. Markdown Normalizer cleans up model output. OpenWebUI Skills Manager Tool manages skills, and the GitHub Copilot Official SDK Pipe connects Open WebUI to the Copilot SDK. The topics list adds agent, memory, MCP, data analysis and data visualization, so the collection reaches beyond document export.
Who it is for: someone running their own Open WebUI who wants a mind map button or an Excel export without writing the plugin themselves. It is not aimed at teams who need a vendor to answer a support ticket.
How Open WebUI plugins load, and what that means for this repository
The mechanism is Open WebUI's own plugin system, not something this repository introduces. A filter intercepts messages in the request path and can modify them before or after the model call. A pipe presents itself as a model, so selecting it in the chat UI routes the conversation through your Python code. A tool exposes callable functions the model can invoke. The repository publishes all three kinds, and the naming in the topics list (openwebui-filter, openwebui-pipe, openwebui-tool) maps directly onto them.
That architecture shapes the failure modes. A filter sits in the critical path of every request it is enabled for, so a slow or throwing filter degrades chat for the user, not just for the feature it implements. Async Context Compression is the clearest example of a plugin whose entire purpose is to intervene in the request path: it rewrites conversation history before the model sees it, which means its correctness is not cosmetic. A pipe, by contrast, is opt-in per conversation because the user has to select it. The export plugins are closer to tools or post-processing steps, which is why they can fail loudly without breaking a normal chat turn.
The repository also carries a skills manager and a Copilot SDK pipe, which points at a different integration style: rather than transforming a message, the pipe delegates the conversation to an external agent runtime. The README does not document the data flow between Open WebUI and the Copilot SDK in the material available here, so treat that pipe as the one requiring the most reading before you enable it.
Installing a plugin from this collection
Installation follows Open WebUI's normal plugin workflow rather than a package manager. The repository does not present a pip install path in the material available; the plugins are distributed as Python source and imported into the instance through the admin interface, the same way other Open WebUI filters, pipes and tools are added. Each plugin is also published as a post on openwebui.com, and those post URLs are what the README links to, for example the Smart Mind Map post and the OpenWebUI Skills Manager Tool post.
Because the collection is a repository of independent plugins, there is no single entry point and no shared configuration file to set. Configuration happens per plugin inside Open WebUI, using the valves mechanism that Open WebUI provides for filters, pipes and tools. The README in the material supplied here does not enumerate the individual valve keys for each plugin, so the authoritative source for a given plugin's settings is that plugin's own file and its openwebui.com post rather than this README.
The practical sequence is: pick the plugin, read its Python file in the repository, import it into Open WebUI, then set its options in the admin panel. The repository's default branch is main and the licence is MIT, so the source is readable and reusable. For anything that touches the request path, read the file before enabling it. That is not caution for its own sake; a filter you have not read is code you are running on every message.
Release cadence and the maintenance question
The release history is the most informative part of the repository. Releases are batched. release-2026.07.14 bundles Export to Excel v0.3.11, Smart Mind Map v1.0.3, Export to Word Enhanced v0.5.3, Smart Infographic v1.6.3 and Flash Card v0.2.5. release-2026.09.04 bundles Flash Card v0.2.6, and a separate tag, openwebui-skills-manager-v0.3.4, ships the skills manager on the same day. The last push to the repository is 2026-09-04.
Two things follow. First, updates arrive in coordinated waves rather than per-plugin, so a fix to one plugin can arrive alongside version bumps to unrelated ones. If you only care about one plugin, you still read a multi-plugin release note. Second, version numbers are not synchronised across the collection: Smart Infographic is at 1.6.3 while Flash Card is at 0.2.x and the skills manager is at 0.3.4. The maturity of each plugin has to be judged individually, and the version string is the only signal the repository gives you.
The README's community stats table, with its badge endpoints for downloads, views, upvotes and saves, is a popularity display. It is not evidence that a plugin is maintained or correct, and it should not be read as such. The release tags are the maintenance signal; the badges are not.
The MIT licence is permissive: it allows use, modification and redistribution, and it disclaims warranty. That disclaimer matters more than usual here, because the README frames the collection as personal work. If you fork and adapt a plugin for your own deployment, the licence permits it. Whether the original author will merge your change is a separate question, and nothing in the material indicates a contribution process beyond the All Contributors badge listing ten contributors.
Where this collection is the wrong tool
The clearest limitation is stated by the project itself. A collection "developed and curated for personal use" optimises for one deployment's needs. There is no stated support policy, no compatibility matrix tying plugin versions to Open WebUI versions, and no deprecation notice process described in the material. If Open WebUI changes its plugin interface, the plugins in this repository break until the author updates them, and the batching means that update may arrive with several unrelated version bumps attached.
The second limitation is scope. If you need one specific capability, for example exporting a conversation to Excel, you are pulling in a repository whose other plugins you will not use, and whose release notes you will have to read anyway to find out whether your plugin changed. The repository does not offer per-plugin release feeds in the material available.
The third is the request-path plugins. Async Context Compression and Markdown Normalizer change what the model receives or what the user sees. Compression in particular is a lossy operation by nature: it reduces history, and the repository's own framing of it as a context-window remedy means the trade-off between token count and retained detail is real. The material here does not document how that trade-off is tuned, so if your workload depends on long-range recall, test the compression behaviour on your own conversations before enabling it broadly.
Finally, if you need a plugin with a named maintainer, a response-time commitment or an audit trail, this is not that. It is one author's collection, published under MIT, with a public release history you can inspect.
How this differs from writing the plugin yourself
The realistic alternative is not a competing plugin marketplace; it is writing the filter, pipe or tool directly against Open WebUI's plugin API. The difference in approach is concentrated in who owns the interface risk. A self-written plugin is code you understand line by line, and when Open WebUI changes, you are the one who updates it. A plugin from this collection is code you read once and then track through release tags, and when Open WebUI changes, you wait for the author or you fork.
That trade is favourable for the visualisation and export plugins. Smart Mind Map, Smart Infographic and the Excel and Word exporters implement rendering and file-format work that is tedious to write and easy to verify by looking at the output. Adopting them saves real effort, and a break is visible: the export fails or the diagram does not render.
The trade is less favourable for the request-path plugins. Compression and normalisation logic encode judgement about what to keep and what to discard, and that judgement is tuned to the author's usage. Writing your own version forces you to make that judgement explicitly for your workload. Adopting the existing one means inheriting a decision you did not make and cannot see the rationale for in the supplied material.
The middle path is to fork. The MIT licence allows it, the Python source is in the repository, and forking converts an external dependency into an internal one with a known owner. For the Copilot SDK pipe, which integrates an external agent runtime, that path is worth considering before enabling it in a shared instance.
What to check before you install anything from this repository
Verify three things. First, that the plugin you want appears in a release tag and that the version on openwebui.com matches the version in the repository. The README shows the two can drift: the AI Task Instruction Generator is listed in the popular plugins table with a version of N/A, which means the repository does not state a version for it.
Second, read the plugin's Python file for the options it exposes through Open WebUI's valves. The README in the material supplied here does not list them, so the file is the documentation. For a filter, confirm what it does to the message payload and whether it can raise an exception that would fail the request.
Third, decide whether you are adopting or forking. Adopting means tracking the batched releases and accepting that a fix arrives on the author's schedule. Forking means you own the update, which is the right call for the request-path plugins and for the Copilot SDK pipe if it runs in an instance other people depend on. The repository gives you the source and the licence to do either. It does not give you a support contract, and it does not claim to.
Editorial conclusion
Adopt this collection if you already run Open WebUI and want export, visualisation or context-management plugins that you can read in full before installing, and if you are comfortable tracking the release tags for fixes. Do not adopt it as a dependency for a product or for a multi-tenant deployment where an unmaintained plugin becomes an incident. Before installing anything, verify that each plugin's version matches a release tag in the repository, and check whether the plugin you need has been touched since the last multi-plugin release on 2026-09-04.
Community notes