Flowbite is a Tailwind plugin plus a data-attribute script, and you need both halves

Styling and behavior arrive through separate installs

Flowbite is added to an existing Tailwind CSS project, and the npm path assumes Node.js and Tailwind CSS are already present. The guide targets Tailwind v4. The package comes first:

npm install flowbite

Then the CSS side needs two registrations in your main input.css. The plugin line adds the component styles:

@plugin "flowbite/plugin";

The source line tells Tailwind to scan the package so its utility classes survive the build:

@source "../node_modules/flowbite";

The interactive parts are a third step. A script tag before the end of the body pulls in the JavaScript that powers modals, dropdowns and similar elements:

<script src="../path/to/flowbite/dist/flowbite.min.js"></script>

The consequence is that a project can look correct while nothing opens or closes. If you add the plugin and skip the script, the markup renders with Flowbite styling and no behavior. The script path shown is a placeholder you must point at your own copy of the file.

Four theme imports, and the default one reaches out to Google Fonts

After installing, you import theme variables into input.css and choose one of four themes. The default theme pairs with the Inter font, loaded from Google Fonts with an import url line, followed by the theme import:

@import "flowbite/src/themes/default";

The minimal theme pairs with Open Sans and uses this import:

@import "flowbite/src/themes/minimal";

The enterprise theme pairs with Shantell Sans:

@import "flowbite/src/themes/enterprise";

A playful theme is the fourth option. Each theme is a commented block in the sample, so you uncomment exactly one and leave the others off. Every theme sample starts with a Google Fonts stylesheet import, which means your page makes a request to Google's font servers unless you replace that line with a self-hosted font. If your project has a strict content security policy or a privacy requirement about third-party requests, that line is the first thing to change.

Interactivity is wired through data attributes, so ids must match

The preferred way to use the interactive components is the data attributes interface. For a modal, a trigger element carries data-modal-target pointing at the modal's id, plus data-modal-toggle, data-modal-show or data-modal-hide to choose the action. In the sample, a button with data-modal-target="defaultModal" and data-modal-toggle="defaultModal" controls a div whose id is defaultModal, which starts with the hidden class and aria-hidden set to true.

When you import the main file through a bundler, with this line, every component and every data attribute works out of the box:

import 'flowbite';

That file has access to all components and applies event listeners to the data attributes automatically. The cost of the convention is that the link between trigger and target is a plain string. A typo in the id does not raise an error you can catch at build time, so a modal that refuses to open is usually a mismatched id or a missing script. The bundled file is described as UMD ready for Webpack or Parcel.

Framework apps must call initFlowbite themselves

Outside plain HTML, the data attribute listeners have to be attached by code you write. The Vue and Nuxt example imports initFlowbite and calls it once the component is mounted:

<script setup>
import { onMounted } from 'vue'
import { initFlowbite } from 'flowbite'

// initialize components based on data attribute selectors
onMounted(() => {
    initFlowbite();
})
</script>

The initFlowbite function sets up the init functions for dropdowns, modals, navbars, tooltips and the other categories so they hook onto the data attributes. If you want less, each category class can be initialised separately with initDropdowns or initModals.

The consequence is a timing responsibility that sits with you. The call belongs after the markup exists. The package keywords mention React, Vue, Angular, Svelte, Next, Nuxt, Astro, Laravel, Django, Flask and Rails, and the table of contents has framework sections, but the Vue example is the one pattern spelled out here, so check the framework section on flowbite.com for the others.

The CDN snippet contains an unrendered template placeholder

The CDN route is described as the quickest way to start. It needs a stylesheet in the head tag and a script before the end of the body. Both URLs point at jsdelivr and share a version segment. In the repository README, that segment is written as a Hugo shortcode instead of a number, so the stylesheet line reads:

<link href="https://cdn.jsdelivr.net/npm/flowbite@{{< current_version >}}/dist/flowbite.min.css" rel="stylesheet" />

The script line has the same pattern:

<script src="https://cdn.jsdelivr.net/npm/flowbite@{{< current_version >}}/dist/flowbite.min.js"></script>

If you paste either line as shown, the URL will not resolve, because current_version is a template variable that the documentation site fills in. Replace it with a real version, for example the package.json value of 4.0.2. The README adds that the best way to work with Tailwind CSS and Flowbite together is to purge unused classes, so the prebuilt CDN stylesheet is a way to try components quickly, not a production setup.

A programmatic API exists for callbacks the data attributes cannot express

For cases where data attributes are too limited, Flowbite offers an API that supports both CJS and ESM. You import a component class such as Modal, select an element, and pass options. The sample reads a node with querySelector on the id modalEl and builds an options object with placement set to bottom-right and a backdrop setting, with further options beyond that.

The package.json sets main to lib/cjs/index.js, module to lib/esm/index.js, types to lib/esm/index.d.ts and style to dist/flowbite.min.css, so TypeScript users get type declarations and bundlers pick the ESM build. There is also an mcpName entry, io.github.themesberg/flowbite-mcp, naming a related MCP server.

The limit is documentation depth. The snippet shows a Modal instance and not the full list of options or callbacks, so anything beyond placement and backdrop must come from the JavaScript section of the docs. Expect to read those pages before relying on callbacks in production code.

Tailwind v4 is the target, and the last tag is from May 2026

The guide works with Tailwind v4. Projects still on Tailwind CSS v3 are pointed to a separate upgrade guide on flowbite.com, and the old tailwind.config.js and plugin-windicss.js files remain in the repository root. If you cannot move to v4, this version's install steps do not apply to you.

The repository is not archived. The last push was on 2026-06-27. Releases are v4.0.0 on 2025-11-12, v4.0.1 on 2025-11-17 and v4.0.2 on 2026-05-13, so the gap between the two newest tags is about six months. The license is MIT, the author is listed as Bergside Inc., and the main branch is main.

The repository also doubles as the documentation site, with Hugo, webpack and Tailwind CLI scripts in package.json plus content and layouts folders. For the question of whether Flowbite is free, the library is MIT licensed, while the table of contents also lists a Pro version, Flowbite Blocks, Icons, a Figma design system and a GPT. Those are separate sections whose terms live on flowbite.com.

Editorial conclusion

Flowbite suits teams already on Tailwind CSS v4 who want ready markup for modals, dropdowns and navbars with behavior driven by data attributes. It is a weaker fit for Tailwind v3 projects that cannot migrate and for anyone who needs the CDN route to work by copy and paste. Confirm the Pro version terms on flowbite.com before assuming everything you see there is in this MIT repository.

Frequently asked questions

Official sources

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