# Tabler: a Bootstrap 5 admin UI where the default branch is dev, not the release > Tabler ships one CSS file, one JS file and Bootstrap 5 inside the npm package, with 120-odd demo pages and 6,000 matching icons. The details that decide a project are in the build repo rather than the docs: a dev branch as default, changesets for versioning, SRI scripts for the CDN, and a docker-compose that exists to run the preview and docs sites. **tabler/tabler** — Tabler is free and open-source HTML Dashboard UI Kit built on Bootstrap - Repository: https://github.com/tabler/tabler - Website: https://tabler.io - Stars: 41,791 · Forks: 4,431 - Language: Astro - License: MIT - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/tabler-tabler ## One stylesheet, one script, and Bootstrap already inside Tabler is a free and open source HTML dashboard UI kit built on Bootstrap 5, MIT licensed, and its quick start is a static page with no build step at all. The whole demo is one stylesheet link and one script tag, which is the claim to hold on to: a button is styled by `tabler.min.css`, and every component you see in the 120-odd demo pages comes from the same two files. ```html Tabler demo

Hello, Tabler!

``` The package route is one install and two imports: ```sh npm install @tabler/core ``` ```js import '@tabler/core/dist/css/tabler.min.css' import '@tabler/core/dist/js/tabler.min.js' ``` A ZIP release, and a tabler-starter template you can open on StackBlitz, CodeSandbox or GitHub Codespaces without installing anything, cover the rest. The live demo is at preview.tabler.io and the documentation at docs.tabler.io. ## Bootstrap 5 travels with the package, so a second copy is your problem The reason one stylesheet is enough is that Bootstrap 5 ships inside the package. That is a good default and a specific constraint. An application that already loads Bootstrap from its own dependency graph now has two: the one Tabler compiled in, and the one the rest of the app uses. Nothing in the kit reconciles the two, and there is no documented switch to drop the bundled copy, so a team that wants one Bootstrap for a site and an admin panel has to work that out outside the package. What the kit does offer is theming from either direction. Sass sources sit at `scss/` and the README points at `@use … with ()` for configuration, and CSS custom properties work for the same purpose without a build step. So customization is not the constraint; duplicate CSS is. The package layout under `dist/` is css, js, libs, types, fonts and img, which is the shape of a presentation layer, not an application: the auth screens and dashboards in the demo are pages to copy, and there is no data layer or router in the box to inherit. ## @latest in the snippet, 1.6.1 in the release feed The quick start links `@tabler/core@latest` in both the stylesheet and the script tag, which is convenient and unpinned. The releases move quickly enough to matter: @tabler/core@1.5.1 on 2026-09-09, 1.6.0 on 2026-09-25 and 1.6.1 on 2026-09-28, with the last push to the repository on 2026-09-29. Copy the snippet as written and a page that worked yesterday can pick up a new minor without you changing anything, with no lockfile to tell you what it is running. The build repo takes that seriously, which is the more useful signal. Two scripts, `generate:sri` and `check:sri`, exist to produce and verify subresource integrity hashes, and integrity hashes are only meaningful against a fixed version, so the maintainers generate them and the CI checks them. There is also `bundlewatch` for tracking asset size, and `check:compat` with a fixture for browser support, alongside a `.browserslistrc` at the root. Pin the version in production and treat the snippet as a demo. ## dist/css is split, and every file doubles into .min and .rtl The stylesheets are deliberately separable. `tabler.css` is enough for most projects, and the neighbours add country flags, payment provider logos, social icons, marketing layouts, alternative gray palettes and vendor styles, each shipped in a `.min` and an `.rtl` version. The JavaScript side is three files: `tabler.js`, `tabler.esm.js` and a standalone `tabler-theme.js` that can be loaded on its own when you only need the dark mode toggle. The weight sits in `dist/libs`, where more than 20 plugins are bundled for the demo pages, including ApexCharts, Tom Select, Vanilla Calendar Pro and FullCalendar. That is what makes the 120-odd demo pages work without you wiring anything, and it is also the part to look at before shipping: those are third-party libraries inside your node_modules, and the README does not itemize their licenses next to the kit's own MIT grant. If you load `tabler.min.css` and `tabler.min.js` only, you skip the plugins, and any demo page you copy that needs a chart or a date picker will need the matching library yourself. ## The Dockerfile runs two sites, and the compose file protects node_modules Contributing means running the preview site and the documentation site, and the repository ships a container for exactly that: ```dockerfile FROM node:22-alpine WORKDIR /app # pnpm via corepack, pinned by the "packageManager" field in package.json RUN corepack enable COPY . . RUN pnpm install --frozen-lockfile # preview website EXPOSE 3000 # documentation website EXPOSE 3010 ENTRYPOINT [ "pnpm", "run", "start" ] ``` The compose file builds that image, publishes 3000 and 3010, and mounts `core`, `preview`, `docs` and `shared` into `/app`. It also adds three anonymous volumes for `/app/core/node_modules`, `/app/preview/node_modules` and `/app/docs/node_modules`, with a comment saying they keep the node_modules installed in the image from being overwritten by the mounts. That is the whole point of the file: bind-mounting four workspaces would otherwise hide the installed dependencies, and the three anonymous volumes are there to put them back. Node 22 with pnpm through corepack is the supported environment, `--frozen-lockfile` means a lockfile that does not match package.json fails the install instead of silently resolving, and the compose service sets `tty: true` so the dev servers keep running interactively. ## Screenshots are a workspace package kept out of the dev run The root is a monorepo: pnpm workspace, Turbo, a lockfile, and a `screenshots/` directory that is its own package. The dev script makes that explicit, excluding it by filter: ```sh turbo dev --filter=!@tabler/screenshots ``` with a separate `dev-screenshots` script for when you do want it. The screenshots package is how the 120-odd demo pages at preview.tabler.io get their images, and the build script ends in `turbo build && pnpm run zip-package`, so the published zip is produced by the same pipeline. What that means for you is a fork that keeps the UI kit and loses the image machinery, because the screenshot run is wired into this repository's scripts rather than into the npm package. If you fork Tabler to rebrand it, the demo pages still build, but the generated preview images do not regenerate on their own, and the alternative is wiring `dev-screenshots` into your own release steps. ## CI checks design tokens, class names and generated HTML The checks in `package.json` describe how carefully the kit is maintained, and each one names a specific risk. `generate:tokens` and `check:tokens` keep the design tokens and the CSS in step. `check:css-vars` guards the custom properties. `check:markup-classes` verifies that class names used in the markup exist in the kit, which is how a renamed utility does not reach the demo pages. `check:html`, `check:compat` and `check:compat-fixture` cover markup and browser support, `check:docs-links` catches dead links in the documentation, and `check:open-source` is a licence audit for the bundled dependencies. There is also an `html-diff` script with a `html-diff:baseline` companion, so generated HTML is compared against a stored baseline. All of that guards Tabler's own pages. None of it inspects the pages you build. A class you copied in 1.5.x can be gone in 1.6.x, the tokens will have moved, and the only signal you get is whatever UPGRADE.md says, which is why that file is the first thing to read when you bump the version. ## Conclusion Use Tabler when you want an admin panel or dashboard that looks finished this week and you are willing to treat Bootstrap 5 as part of the kit rather than something you share with the rest of your app. Do not reach for it if you need an application framework, because the package is styles, one script and a set of static demo pages with no data layer or routing of its own. Before you commit, pin the version rather than tracking the default dev branch, check which optional stylesheets in dist/css you actually load, and read UPGRADE.md, since releases such as 1.6.1 on 2026-09-28 arrive with changesets behind them and the docs site is the only migration note. ## FAQ ### What is Tabler used for? It is a free and open source HTML dashboard UI kit built on Bootstrap 5, meant for admin panels, dashboards and web apps. The project describes it as a set of ready-made layouts, components and demo pages, each working in light and dark mode and customizable with Sass or CSS custom properties, with more than 120 demo pages in the live demo. ### How do I install the Tabler UI kit? Either link the CDN files, add `npm install @tabler/core` and import `dist/css/tabler.min.css` and `dist/js/tabler.min.js`, or download the latest release as a ZIP archive. To try it without installing, open the tabler-starter template on StackBlitz, CodeSandbox or GitHub Codespaces, and the installation guide at docs.tabler.io has the remaining options. ### Is Tabler still being updated? Yes, with fast patch cadence. Releases @tabler/core@1.5.1, 1.6.0 and 1.6.1 were published on 2026-09-09, 2026-09-25 and 2026-09-28, and the last push to the repository was on 2026-09-29. Versions are produced by changesets, so UPGRADE.md is the migration note to read between releases. ### What is the difference between the Tabler UI kit and Tabler Icons? They are separate projects that share a look. The UI kit is the Bootstrap 5 dashboard and admin component set published as @tabler/core, while Tabler Icons is a separate repository of over 6,000 MIT-licensed SVG icons drawn on a 24x24 grid to match the kit, with packages for React, Vue, Svelte and Angular. Tabler also publishes Illustrations, Emails and Avatars as their own projects. ### Does Tabler work with React, Vue or Laravel? Tabler is plain HTML and CSS, so it drops into any framework, and the documentation has a setup guide for React, Vue, Angular, Next.js, Nuxt, SvelteKit, Astro, Laravel, Django, Rails and Symfony. The framework-specific work is wiring the CSS and JS into your build, not importing Tabler components. ### Why do my Tabler pages look unstyled, or why is a demo widget empty? Check which file you loaded. The stylesheets are split so you load only what you use, and `tabler.css` alone covers most projects while flags, marketing, payments, socials, themes and vendors live in separate files with .min and .rtl versions. Plugins for charts, date pickers and selects sit in `dist/libs` and are not part of `tabler.min.js`. ## Sources - [Official documentation](https://tabler.io) - [Official README](https://github.com/tabler/tabler#readme) - [Project repository](https://github.com/tabler/tabler) - [Release notes](https://github.com/tabler/tabler/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tabler-tabler