TabBlazor is a Blazor component library and admin template on Tabler UI

A component library and a template in one package

TabBlazor is described as a Blazor component library and admin template built on the Tabler UI framework, and the homepage at tabblazor.com doubles as a live demo with hundreds of working examples with source.

That dual nature is the point. Most component libraries give you the pieces and leave the shell to you; most admin templates give you the shell and lock you into their components. This one ships both, with a documented demo site that functions as the reference for how each component is meant to be used.

The feature list gives the scale: 90 or more Razor components covering forms, tables, modals, dashboards and navigation. Around that sit four decisions worth noting.

Validation is pluggable. DataAnnotations is the default, but you can bring your own `IFormValidator`, which matters if your application already has a validation story or uses a different annotation set.

The modal and offcanvas components come with async result patterns, so a modal can return a value to the caller rather than only closing.

There is a dark and light theme switch.

And the JavaScript interop is minimal, with most components being pure C# and CSS. That is a real design constraint rather than a claim, because a component library that needs a script tag per widget is a component library you cannot use in a partial page, an email-rendered view or a static site generator output.

The project is C# and MIT licensed, on the `master` branch, with the last push on 2026-10-19. The releases are named as betas: 1.6.24-beta from 2026-10-19, 1.6.7-beta from 2026-10-09 and 1.6.6-beta from 2026-10-01, which is the version numbering to plan around if you pin a package version.

The lineage is stated in the credits: the project was originally based on Tabler.Blazor by zarxor, with the UI framework being Tabler.

Installing the package and registering the service

The install is two package references, one of them optional:

dotnet add package TabBlazor
dotnet add package TabBlazor.QuickTable.EntityFramework   # optional, EF Core integration

The second package is the Entity Framework Core integration for QuickTable, and it is shipped separately so that a project which does not use EF Core does not take the dependency.

Then the services are registered in `Program.cs`:

builder.Services.AddTabBlazor(options =>
{
    options.EnablePopper = true;   // optional, enables dynamic tooltip/dropdown positioning
});

`EnablePopper` is the single option shown, and it is the opt-in for popper.js positioning of tooltips, dropdowns and similar floating elements. The feature list calls popper.js positioning opt-in, so the default is off and the library works without it.

Next the namespace goes into `_Imports.razor`:

@using TabBlazor

And finally the styles and scripts are referenced in `App.razor`, or in `index.html` for WebAssembly:

<link rel="stylesheet" href="https://unpkg.com/@tabler/[email protected]/dist/css/tabler.min.css" />
<link rel="stylesheet" href="_content/TabBlazor/css/tabblazor.min.css" />
<script src="_content/TabBlazor/js/tabblazor.js"></script>

Those three lines are where the design of the library becomes visible. Two stylesheets are needed: Tabler core from unpkg, which carries the whole Tabler look, and the TabBlazor stylesheet served as a static web asset from the package, which carries the component specific styling. Then a single JavaScript file from the package.

So the JavaScript your application ships is one file, and the rest of Tabler's behaviour lives in CSS. That is consistent with the claim about minimal interop.

The unpkg reference also means the base styling comes from a CDN at a pinned version, 1.6.0 in this snippet. For a deployment behind a firewall, or one with a content security policy, or one that prefers to pin and self host assets, that reference is the line you have to change, and the version you pin has to match what the components were built against.

What a component looks like in Razor

The quick example in the README is the fastest way to see the shape of the API:

<Card>
    <CardHeader>
        <CardTitle>Hello, TabBlazor</CardTitle>
    </CardHeader>
    <CardBody>
        <Button BackgroundColor="TablerColor.Primary" OnClick="Save">Save</Button>
    </CardBody>
</Card>

Three things are visible. The components are named after the HTML elements they wrap, Card, CardHeader, CardTitle, CardBody, which is the convention Tabler itself uses and which keeps the markup readable. The colour is an enum rather than a string, `TablerColor.Primary`, so a typo is a compile error. And the event handler is a plain `OnClick="Save"` attribute that binds to a method, with no event callback plumbing or lambda required.

The nesting is the Tabler card pattern exactly, so anyone who has written Tabler markup in another stack will read this without translation.

The demo site is where the rest of the library is documented in practice. The README points at it for hundreds of working examples with source, which for a component library is a better reference than a documentation site, because you can see the markup and the result side by side.

For getting started, there is a separate template repository, TabBlazor.Templates, with project templates for a new project. That is worth knowing about because it is the difference between an empty solution with a package reference and a solution with an admin shell, navigation and layout already wired.

The demo application itself lives in the repository under `docs/Tabler.Docs.Wasm`, and the README gives the command to run it locally:

cd docs/Tabler.Docs.Wasm
dotnet run

A WebAssembly host for the documentation is a sensible choice for a component library, since it runs in the browser without a server to install, and it means the demo you see is the demo that runs.

For the full solution, the build and test commands are:

dotnet build TabBlazor.slnx -c Release
dotnet test

Note the `.slnx` extension. That is the newer XML solution file format, and it means the repository needs a recent .NET SDK to open, which is a constraint if your CI images are pinned to an older toolchain.

QuickTable, and why EF Core is a separate package

QuickTable is the component that gets its own section in the feature list, and the reason is that a data grid is where a component library either earns its keep or does not.

The description is specific about what it does: virtual scrolling, sorting, filtering and grouping, with optional EF Core integration. Four capabilities, and the first one is the important one for large data. Virtual scrolling means the component renders only the rows in view, so a table over a hundred thousand records behaves like a table over a hundred.

The Entity Framework Core integration is a separate NuGet package, `TabBlazor.QuickTable.EntityFramework`, and it is optional in the install line. The design reason is straightforward: EF Core is a heavy dependency with a specific data access model, and a component library that forced it on every consumer would be much harder to adopt. Splitting it out means the QuickTable component itself can work with any data source, and the EF Core path is an opt-in adapter.

The four capabilities also interact in the way you would expect from a grid that has been built up over releases. Sorting, filtering and grouping are all server-friendly operations, which is what makes the EF Core integration worth having, since a grouped and filtered query can be pushed down to the database rather than applied to a client-side list.

The other component families in the list, forms, modals, dashboards and navigation, are the surrounding set that an admin interface needs. Dashboards are where the template half of the project shows, since a dashboard is mostly layout and a chart placeholder, and navigation is where the admin template half shows, since a sidebar and a breadcrumb are layout decisions that every admin application otherwise reinvents.

The project also carries a `DEVIATIONS.md` at the root, which is a file worth opening before you adopt the library. A deviations document in a component library records where it differs from the underlying framework, here Tabler, and it is the honest way to answer the question of what happens when you want the Tabler behaviour but the component does something different.

The theme switch, the script, and the repository shape

The dark and light theme switch is worth a moment because it is the kind of feature that is either trivial or impossible depending on how the underlying CSS is built.

Tabler is a CSS framework, and its dark mode works by a class or attribute on a root element plus CSS custom properties for the palette. A component library built on top of that inherits the mechanism rather than reimplementing it, which is why a switch can exist without a large amount of JavaScript. The component library's job is to make sure its own stylesheet uses the same variables, and that is why there is a second stylesheet served from the package rather than only the CDN one.

The single JavaScript file is where the remaining behaviour lives, and the popper.js option tells you what some of it does. Tooltips and dropdowns need to be positioned relative to their trigger, and the usual approach is a positioning library, which means JavaScript. By making that opt-in, a project that does not need dynamic positioning does not load the dependency, and a project that does can enable it with one flag in the service registration.

The repository layout is a large solution. There is `src/` for the library and its projects, `docs/` for the documentation and the WebAssembly demo, `Icons/` for the icon set, `tools/` for build tooling, and then the test projects `TabBlazor.Tests/` and `TabBlazor.Linq2GraphQL.Tests/`, which reveal a second product hiding in the repository: a LINQ to GraphQL component that has its own test project.

There is also `Directory.Packages.props`, which is the central package management file, `global.json` pinning the SDK version, `version.json` for the release version, and a `CLAUDE.md` at the root, which tells you the project keeps agent instructions in the tree.

The CI badge at the top of the README points at a workflow called `ci.yml` on the `master` branch, so the build is checked continuously on that branch.

When a different choice is the right one

There are two cases where this is the wrong library, and both are about the dependency on Tabler rather than about Blazor.

The first is styling. The components are built on Tabler, and the Tabler stylesheet comes from a CDN at a pinned version. If your application has its own design system, or if you need to match an existing product's look precisely, you are fighting a framework that a component library is built on. The alternatives in that case are a Blazor component library that is design-neutral, where you supply the styling, or writing the components yourself against your own CSS. The difference in approach is who owns the visual language: TabBlazor delegates it to Tabler, which gives you a coherent interface for free and takes away your ability to restyle it.

The second is tables at scale. QuickTable has virtual scrolling, sorting, filtering and grouping, and the EF Core integration. If your data is large and your queries complex, a grid component is convenient but the performance ceiling is set by the component, and the serious answer for very large datasets is a server-driven grid where paging, filtering and sorting all happen in the database. That is a different kind of work, and the library is not that.

There is also the beta versioning to weigh. The recent tags are 1.6.24-beta, 1.6.7-beta and 1.6.6-beta, which means you are adopting a 1.6 line that is still being adjusted, and a version number that will change. For an application you ship, that is a pin you will revisit; for a prototype, it does not matter.

And the third consideration is the base framework. TabBlazor builds on the Tabler UI framework, and the credits record that the project was originally based on Tabler.Blazor by zarxor. An application that needs something Tabler does not have, or a component that Tabler renders differently, will run into that boundary, which is what the DEVIATIONS.md file is there to describe.

Editorial conclusion

Adopt TabBlazor when you are building a Blazor application that needs an admin interface and you would rather write Razor against 90 or more ready components than assemble your own, especially if you want tables with virtual scrolling and an Entity Framework Core data source. Do not adopt it if you cannot accept a beta component library, since the recent releases are 1.6.24-beta, 1.6.7-beta and 1.6.6-beta, and note that the stylesheet reference points at the Tabler core CDN at version 1.6.0, so the look depends on a version you do not control. Verify first that the Tabler core version you reference matches what the components expect, that the `options.EnablePopper` flag is what you want for tooltip positioning, that the validation provider you use implements `IFormValidator`, and that your build tooling handles the `TabBlazor.slnx` solution file.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TabBlazor/TabBlazor on GitHub