Navbar Card: one navigation bar for every Lovelace dashboard

A card that changes shape with the viewport

The project's own description says it displays a bottom nav on mobile devices and a side nav on desktop devices for easy navigation, and the README restates the design goal as making navigating your dashboards effortless and elegant while adapting to a phone, a tablet or a desktop. The dual layout is the whole idea and it is the reason the card exists as a card rather than as a theme. A Home Assistant dashboard is often several separate views, one per room or per function, and switching between them normally means either the sidebar, which is a global control that does not belong to a view, or a set of navigation cards typed into each view by hand. One card that renders a bar at the bottom on a narrow screen and a rail on a wide one removes the duplication, because the same configuration produces the right shape on both.

The four reasons it claims

The README lists what the card is for in four bullets, and they are worth reading as a requirements list rather than as marketing. Unified navigation across all your dashboards, which is the duplication problem described above. A responsive layout that automatically adapts to screen size, which is the mechanism rather than the goal. Customisable actions, icons and styles, which is what keeps it usable when it sits inside somebody else's carefully designed view. And simple setup with integration into existing Lovelace views, which is the claim that decides whether anybody tries it. The visual reference is stated as Adaptive Mushroom and Google's Material Design, both of which are visible in the result, and the card is described as minimal, responsive and easy to configure.

A Lit component with Home Assistant's own helpers

The package manifest describes the implementation. It is a TypeScript project whose runtime dependencies are lit at version 3.3.3, custom-card-helpers at 2.0.0, home-assistant-js-websocket at 9.7.0, @kipk/load-ha-components for pulling in Home Assistant's own components, and the @open-wc/scoped-elements and testing-helpers packages from the Open Web Components group. Lit is the component model, custom-card-helpers is the conventional way for a Lovelace card to talk to the Home Assistant frontend, and the websocket client is how a card subscribes to state changes without polling. The scoped-elements package is the mechanism that lets a card register its own element names without colliding with other custom cards on the same page, which matters in a dashboard that may load several.

The build is Bun with TypeScript and Biome

The build script in the package manifest is a single line that does two things: it runs the TypeScript project build with tsc -b, and then bundles the entry point with bun, setting NODE_ENV=production and pointing the output at dist/navbar-card.js for the browser target. The choice of Bun over webpack or Vite is a choice about a project that ships one JavaScript file into other people's dashboards, where the size and the build time of that artefact are what the maintainer feels. Alongside it, the toolchain is TypeScript 7, Biome for both linting and formatting, Prettier in the dev dependencies, and Vitest with a jsdom environment and the Open Web Components testing helpers for the test suite. The test scripts cover a plain run, a watch mode and a coverage variant.

Distribution is through HACS, and the docs live off the repository

The repository root carries a hacs.json file, which is what makes the card installable through the Home Assistant Community Store, and there is a docs directory containing the published site. The README itself is short and points elsewhere for most of what a user needs. Installation has its own guide page, a quickstart page for building a first navbar, a configuration page listing all options, an examples page for what other people have built, and a support page. That split is unusual enough to be worth noting: the README is a signpost and the documentation site is the manual, which is a common pattern for Home Assistant custom cards and means the code repository alone does not tell you much about what the card can be configured to do. The forum thread badge points at a Home Assistant Community discussion, which is where the design questions usually get settled.

Versioning and licence

The release history moves quickly and the tags are named after the card rather than the repository. NavbarCard v1.7.1 was published on 2026-10-14, v1.7.0 on 2026-10-12 and v1.6.1 on 2026-06-01, and the last push to the repository was on 2026-10-19. Two releases in three days followed by a gap of four months to the previous one is the pattern of a project that ships when there is something to ship, so pinning to a specific tag in a production dashboard is the safer habit than tracking the main branch. On licensing, the repository's own licence field carries no standard identifier, while the package manifest records MIT with the author given as Jose Álvarez Quiroga. A third-party library in a card that many people install also raises a question the README does not answer, which is what the licences of the bundled dependencies permit for a redistributed build, and that is worth checking before you fork it.

Where Navbar Card is the wrong choice

Four limits apply. It is a Lovelace card, so it only exists inside a Home Assistant dashboard, and it cannot provide navigation in the frontend outside a view, which means it does not replace the sidebar or the drawer. It is a browser-side custom card, so it needs to be registered as a Lovelace resource in every client that loads the dashboard, and a dashboard used by many people is a dashboard where one stale resource registration breaks the navigation for all of them. The responsive behaviour means the card's appearance is decided by the viewport, so if you want a specific layout on a specific device you may find the card fighting your design rather than serving it. And the project is a single maintainer's card with a donation link rather than a supported product, so the pace of fixes depends on that person's time.

Editorial conclusion

Use Navbar Card when your Home Assistant instance has several dashboards and you want one consistent way to move between them from a phone or a desktop wall panel, because the same card adapts its position to the viewport rather than needing a separate configuration per device size. Do not expect it to replace the Home Assistant sidebar or the system drawer, since it is a card you place inside a view, and it adds a resource that has to load in the browser. Verify first which Lovelace views the card points at and that they exist, that the card's resource is registered as a module in your Lovelace configuration, and which release you install, because the version numbering moves fast and the newest tags are v1.7.1 and v1.7.0 from October 2026.

Frequently asked questions

Official sources

1. Issues
2. joseluis9595/lovelace-navbar-card on GitHub
3. Project website
4. README
5. Releases