# CodeBeam.MudExtensions: the community component shelf for MudBlazor
> CodeBeam.MudBlazor.Extensions collects third party components for MudBlazor, the Material Design component library for Blazor, into one NuGet package: date and font pickers, a combo box, a splitter, a gallery, a barcode and code viewer, transfer lists, and Material 3 variants of the switch and text field. Installation is two static asset references and one service registration, and the project publishes a support matrix that maps each extension version to the MudBlazor and .NET versions it works with.
**CodeBeamOrg/CodeBeam.MudBlazor.Extensions** — Useful third party extension components for MudBlazor, from the contributors.
- Repository: https://github.com/CodeBeamOrg/CodeBeam.MudBlazor.Extensions
- Website: https://mudextensions.codebeam.org/
- Stars: 584 · Forks: 103
- Language: C#
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/codebeamorg-codebeam-mudblazor-extensions
## A community shelf rather than a framework of its own
CodeBeam.MudBlazor.Extensions is described as useful third party extension components for MudBlazor, from the community contributors, and the README puts it more plainly: useful third party extension components for MudBlazor, from the community contributors.
That framing matters, because it explains the shape of the project. MudBlazor itself is the Material Design component library for Blazor, and the things it does not ship are the things a community collects here. The project is hosted under the CodeBeamOrg organisation, the package is CodeBeam.MudBlazor.Extensions on NuGet, the namespace the components live in is MudExtensions, and the documentation site is mudextensions.codebeam.org.
Two public surfaces are provided. There are the docs at that site, and a playground at trymudextensions.pages.dev, which the README describes as the place to try MudExtensions and where each example is recorded, with a video per component.
The project is MIT licensed, and the badges point at the usual places: a Discord server, a NuGet version and download count, a Codecov coverage badge for the dev branch, and a contributors graph. The default branch is dev rather than main, which is the normal arrangement for a library that publishes releases from a development line and keeps BreakingChanges.md alongside it.
The audience is Blazor developers who have already adopted MudBlazor and have hit a wall with it. Someone who has not set up MudBlazor at all should read the installation note in this README twice, because this package builds on it rather than replacing it.
## Thirty three components, one utility and four extended variants
The component list in the README is long enough to be worth sorting, because the name alone does not tell you what a component does.
The pickers and colour tools form one group: MudDateTimePicker, MudDateWheelPicker, MudFontPicker and MudColorProvider. The input and selection group covers MudComboBox, MudPasswordField, MudChipField, MudCodeInput, MudInputStyler, MudToggle and MudTransferList. The layout and container group has MudPage, MudSection, MudSplitter, MudScrollbar, MudSpeedDial, MudPopup, MudTeleport, MudGallery and MudWatch. Code and data handling is MudBarcode, MudCodeViewer and MudCsvMapper. Animation and loading states are MudAnimate, MudLoading and MudLoadingButton. A wheel picker and a speed dial round out the interaction pieces, and MudSwitchM3 and MudTextM3 are Material 3 variants of the switch and the text field.
There is a single utility, MudCssManager, and a separate category of extended components: MudListExtended, MudSelectExtended, MudStepperExtended and MudTextFieldExtended.
The extended category is the interesting one for an adopter, because it is not new widgets but alternatives to MudBlazor's own that presumably differ in behaviour, which is the kind of thing you only find by reading the docs for each one.
Nothing in the list is a full application framework. Every entry is a component or a small service, which is what makes the package usable alongside MudBlazor rather than instead of it.
## Installation is two assets and one service registration
The installation notes are short because this is a static-asset package rather than a component library with a build step.
The first step is the stylesheet in the head section of the page, which is index.html or _Layout.cshtml or _Host.cshtml depending on whether you run Server-Side or WASM:
```html
// For MudCodeViewer component only (needs CodeBeam.MudBlazor.Extensions.Code package)
```
The second is the script at the end of the body:
```html
// For MudCodeViewer component only (needs CodeBeam.MudBlazor.Extensions.Code package)
```
The third is registering the services in Program.cs:
```cs
using MudExtensions.Services;
builder.Services.AddMudExtensions();
```
And the fourth is optional but useful, adding the namespace to _Imports.razor:
```razor
@using MudExtensions
```
Two things to notice. The README states that the extension uses MudBlazor features, so you need MudBlazor set up first, and it says the only thing to add is the line described above. And the Code package is separate, pulled in only if you want the code viewer, which brings its own Prism assets for syntax highlighting. That is a good structure, since the syntax highlighter is the heaviest dependency and most applications will not need it.
## The support matrix is the file to read before you upgrade
The README publishes a table mapping each extension version to the MudBlazor version and the .NET version it supports, with a support status in the last column.
The older lines are marked Ended. MudExtensions 6.0.0 to 6.0.3 pairs with MudBlazor 6.0.16 on .NET 6. 6.1.x and 6.2.x and 6.4.x cover a range of MudBlazor 6.x releases on .NET 6 and 7. MudExtensions 6.8.0 to 6.9.2 covers MudBlazor 6.12.0 to 6.21.0 on .NET 6, 7 and 8, and 7.0.0 to 7.1.0 covers MudBlazor 7.0.0 to 7.16.0 on .NET 7 and 8.
The current lines are 8.0.0 onwards against MudBlazor 8.0.0 onwards on .NET 8 and 9 with support marked Limited, and 9.0.0 onwards against MudBlazor 9.0.0 onwards on .NET 8, 9 and 10 with support marked Full.
So the library is on its third major version of MudBlazor alignment, and the pattern of the table is that a MudExtensions major tracks a MudBlazor major, which tracks a .NET generation.
This is a genuinely useful table, and it is also an honest one. Ended means the line no longer receives support, and Limited means the newest line is new enough that the maintainers have not yet declared it fully settled. For a team on .NET 8 with MudBlazor 8, the extension package to pick is the 8.x line.
The companion file BreakingChanges.md, linked from the README, is where the details of those version jumps live, and it is the second thing to read after the matrix.
## A WASM docs site served by Caddy, in a container
The repository is set up so the documentation site itself is a real Blazor application, which is a sensible way to write documentation for a component library.
The Dockerfile has two stages. The build stage uses the .NET 10 SDK image, copies the source, restores the docs project and publishes it in Release into a publish folder. The runtime stage is caddy:alpine, with the published wwwroot copied into the Caddy web root and the repository's Caddyfile installed as the server configuration.
The docs project is the WASM one, CodeBeam.MudBlazor.Extensions.Docs.Wasm, and the compose file runs the published image from the GitHub container registry with the dev tag:
```yaml
services:
mudextensions:
image: ghcr.io/codebeamorg/codebeam.mudblazor.extensions:dev
container_name: mudextensions
restart: unless-stopped
networks:
- edge
```
The compose file attaches the container to an external network called edge, which suggests the playground and the docs are deployed as separate services on a shared network rather than as one stack.
The rest of the repository is conventional: a solution file named CodeBeamMudExtensions.slnx, src/, tests/, benchmarks/, utilities/ and docs/ directories, a Dockerfile, a compose file, a Caddyfile, BreakingChanges.md, CODE_OF_CONDUCT.md and a LICENSE.
The benchmarks directory is worth a second look. For a component library, benchmarks usually exist because the maintainers were worried about a specific complaint, and it is a sign the project is measuring rather than guessing.
## Sass changes need a build flag you have to remember
The last section of the README is a short note about updating the CSS, and it is the kind of detail that saves a contributor an hour.
It says that if you update or create a new scss file you will need to uncomment the MudBlazor.SassCompiler line in CodeBeam.MudBlazor.Extensions.csproj, otherwise the added and changed scss file has no effect on the project.
So the styles in this package are compiled from Sass at build time, and that compilation is off by default. A contributor who adds a rule to an scss file, rebuilds, and sees nothing happen has to open the project file and enable the compiler before the change appears. The README says it plainly, and it is a good example of a documentation line that exists purely because the failure mode is confusing rather than obvious.
It also tells you something about the build. The NuGet package ships a prebuilt MudExtensions.min.css and MudExtensions.min.js, which is what the installation instructions reference, so a consumer of the package never runs the Sass compiler at all. Only someone working on the library itself does.
The examples in the README are videos of the playground, one per component, including MudAnimate, MudCodeInput, MudDateWheelPicker, MudFontPicker, MudGallery, MudInputStyler, MudPopup, MudSpeedDial, MudStepper and MudWheel. For a library whose components are visual, that is the documentation that matters, and the docs site carries the same examples with more detail.
## Conclusion
CodeBeam.MudExtensions suits a Blazor team that has standardised on MudBlazor and finds a handful of components missing, and who would rather add a maintained package than write and maintain their own MudComboBox. It does not suit you if you need components the project does not carry, and it does not suit a team that treats a community package as a stable dependency without reading the support matrix, because the matrix marks several version lines as ended and only the 9.x line as fully supported. Check three things before you adopt it: that the extension version you pick matches the MudBlazor version you are on, that you have read BreakingChanges.md for the jump, and that you know how the stylesheet is built, because a new scss file has no effect until the Sass compiler line in CodeBeam.MudBlazor.Extensions.csproj is uncommented. The last push to the repository was on 2026-10-14 and the newest release is 9.2.0 from 2026-10-06.
## FAQ
### What is CodeBeam.MudBlazor.Extensions?
It is a MIT licensed community package of extension components for MudBlazor, the Material Design component library for Blazor, published on NuGet as CodeBeam.MudBlazor.Extensions. It carries more than thirty components, including pickers, a combo box, a splitter, a gallery, a barcode and code viewer, plus Material 3 variants of the switch and text field.
### How do I install CodeBeam.MudBlazor.Extensions?
Add the MudExtensions.min.css link to the head of your page and the MudExtensions.min.js script to the body, then call builder.Services.AddMudExtensions() in Program.cs and optionally add @using MudExtensions to _Imports.razor. MudBlazor itself has to be set up first, and the Code package is only needed for the MudCodeViewer component.
### Which MudBlazor and .NET versions are supported?
The README publishes a matrix: the 8.x extension line targets MudBlazor 8 on .NET 8 and 9 with support marked Limited, and the 9.x extension line targets MudBlazor 9 on .NET 8, 9 and 10 with support marked Full. All earlier lines from 6.0.0 upwards are marked Ended.
### What are the extended components?
Four are listed separately from the main list: MudListExtended, MudSelectExtended, MudStepperExtended and MudTextFieldExtended. They are alternatives to the MudBlazor originals, so it is worth reading the documentation for each one before choosing between the two.
### How is the documentation site built?
The Dockerfile publishes the WASM docs project with the .NET 10 SDK and serves the result from a caddy:alpine image using the repository Caddyfile, and the compose file runs the published dev image from the GitHub container registry on an external network named edge. A live playground is published separately.
## Sources
- [CodeBeamOrg/CodeBeam.MudBlazor.Extensions on GitHub](https://github.com/CodeBeamOrg/CodeBeam.MudBlazor.Extensions)
- [License: MIT](https://github.com/CodeBeamOrg/CodeBeam.MudBlazor.Extensions/blob/dev/LICENSE)
- [Project website](https://mudextensions.codebeam.org/)
- [README](https://github.com/CodeBeamOrg/CodeBeam.MudBlazor.Extensions/blob/dev/README.md)
- [Releases](https://github.com/CodeBeamOrg/CodeBeam.MudBlazor.Extensions/releases)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/codebeamorg-codebeam-mudblazor-extensions