Frosted Glass: a Home Assistant theme that runs on card-mod or UIX

A theme that cannot render without a styling engine

The most important line in the documentation is a warning, and it is the reason this theme is not a drop in. Frosted Glass requires either UIX or card-mod to render the glass styling, and the installation guide asks you to install exactly one of them through HACS. UIX is described as the actively developed successor to card-mod, and it understands the existing card-mod keys, so the documentation says migration does not require dashboard changes. card-mod remains the option for existing installations that prefer to stay where they are.

The instruction not to install both is not a style preference. Both engines patch the same Home Assistant elements, so running them together means two sets of rules fighting over the same card.

The second subtlety is how the engine is loaded. For styling of the sidebar and the drawer on settings and other panels, the selected engine has to be loaded as a frontend module following its own installation instructions, because a dashboard resource is only loaded on Lovelace dashboards. The theme itself is then applied from your profile, which affects the whole interface, as opposed to a per-view theme, which affects only that view. Get that distinction wrong and the theme looks correct on your dashboard and wrong everywhere else.

Light, Dark and a Lite edition without blur

Three variants are offered. Light and Dark are the two colour modes, and Lite is the same glassmorphism style with the blur removed. Lite exists for a concrete reason: older or low-end devices, where a backdrop filter on every card is expensive. The Lite description is specific about what stays and what goes. Cards keep their transparent backgrounds and their glass edges, while popups stay opaque for readability.

That last detail is a design decision worth crediting. A glass effect that leaves dialogs legible is more usable than one that renders every surface translucent, and the Lite build shows that the theme is not simply a blur switch.

The theme also declares itself ready for Home Assistant 2026.8, using the current form, switch and border-radius theme tokens, with validated single-mode declarations. That is the kind of statement that ages badly, but it is at least a statement about which token set the theme targets rather than a vague promise.

For people who want their own colours, the project points to a separate add-on, Frosted Glass Theme Manager, which lets you pick your own colour and background from the interface instead of editing YAML. The theme manager is a distinct install, and the compatibility table notes that custom colours generated by it flow into the cards, so the two pieces are designed to work together.

Installing through HACS in four steps

The installation path runs through HACS, the community store for Home Assistant, and the theme is published there as a theme category repository. The sequence in the documentation is short.

First, the prerequisites: HACS has to be installed, and exactly one styling engine, UIX or card-mod, has to be added through HACS. Second, the theme itself is added through HACS, using the repository link that appears in the badge at the top of the README. Third, Home Assistant is restarted. Fourth, the theme is activated from the profile, in the bottom left corner of the Home Assistant interface, where Frosted Glass and Frosted Glass Lite appear in the theme dropdown.

There is no YAML editing in that path at all, and the release note for version 1.3 makes a point of the same idea, advertising customisation of colours and backgrounds through the interface with the new theme manager and no YAML. The theme manager is optional, and the optional extra mentioned for the sidebar is the lovelace-navbar-card, which is linked as the way to match the navigation bar shown in the screenshots.

Text-only Markdown cards need a manual opt out

There is a documented rough edge, and the project handles it honestly. A Markdown card that contains only text still receives the theme's glass and border styling, because a theme cannot reliably detect the text-only variant. If you want a genuinely plain card, the documentation supplies a card_mod block that you paste into that card:

card_mod:
  style: |
    ha-card {
      --ha-card-background: transparent !important;
      --ha-card-backdrop-filter: none !important;
      --ha-card-box-shadow: none !important;
      --frosted-glass-card-layer-content: none !important;
      background: none !important;
      backdrop-filter: none !important;
      -webkit-backdrop-filter: none !important;
      box-shadow: none !important;
      border: none !important;
    }
    ha-card::before {
      content: none !important;
      background: none !important;
      backdrop-filter: none !important;
      -webkit-backdrop-filter: none !important;
    }

Read it as a hint about the theme's internals. The card background, the backdrop filter, the box shadow and the border are all set to none, and the pseudo-element that carries the content layer is neutralised with content none. The presence of a --frosted-glass-card-layer-content variable shows that the theme drives its effect through a named custom property on the card, which is the same mechanism the compatibility table describes for the other cards.

Per-card contracts instead of blanket overrides

The compatibility table is the most technical part of the documentation and the most revealing. The stated principle is that the theme uses each card's public CSS variables where they exist, which keeps the integration stable across card updates and lets the custom colours from the theme manager flow into the card.

The per-card behaviour is specific. Bubble Card uses the official surface, border, shadow, popup and select-menu variables, and the blur sits on a background pseudo-element so that fixed-position menus stay out of a filtered containing block, while the outer ha-card does not add a second border or tint. Navbar Card uses the official radius and shadow variables on a transparent surface, with blur applied directly in the standard build and the Lite build keeping it transparent without blur.

stack-in-card is the interesting one, because it suppresses glass and borders on children whose background the card explicitly makes transparent, and the keep.background and --keep-background choices retain their surfaces. That is a theme negotiating with another card's intent rather than overriding it.

This approach is the reason the theme survives card updates. A theme that rewrites internal classes breaks when the card changes its markup, while one that speaks the card's public variables keeps working. It is also why the audit mentioned later matters.

A rendering test suite for a visual theme

Most theme repositories ship CSS and nothing else. This one ships a test harness. The package manifest in the repository root is a small private package whose test script runs two node scripts:

"test": "node scripts/test_theme_rendering.cjs && node scripts/test_glass_pixels.cjs"

The two scripts have suggestive names. One checks theme rendering, the other checks glass pixels, and the single dev dependency is Playwright at version 1.62.1, which is a browser automation tool. The scripts/ directory at the repository root holds them.

For a visual project, that is the correct shape of verification. A CSS theme can look right in a screenshot and be broken in a real browser, and the failure modes are exactly the ones a screenshot hides: a filtered containing block that swallows a fixed-position menu, a pseudo-element that paints over text, a variable that a card stops exposing. Asserting on rendered output and on actual pixels catches those, and it means the compatibility table is a claim backed by checks rather than a promise.

It is also a boundary. The tests can only cover the environments the project sets up, so a card or an engine version outside that setup is your problem to check.

Maintenance, licence and who should switch

The project is under the MIT licence, the last push was on 2026-10-04, and version 1.4 landed on 2026-10-02. Before that came a large 1.3 update in November 2025 that introduced the theme manager, and 1.2.2 a couple of days earlier with card-mod 4.0.0 compatibility and custom backgrounds. The cadence suggests an active project rather than a dormant one, and the version numbers track the Home Assistant and card-mod releases it reacts to.

The version constraints are the part to check. The documentation states that the source audit covers card-mod 4.2.1 and UIX 8.3.1, and that older engines may lack the current drawer hook. That is a precise statement of what was examined, and it tells you that on an older engine you are outside the tested area, with the drawer and sidebar styling being the likely casualty.

The audience is narrow and clear: a Home Assistant user who wants a translucent dashboard, is willing to add a styling engine, and understands that the theme touches every surface in the interface. If you want a dashboard that works everywhere, including on a tablet with an old browser, the Lite build without blur is the version to consider. If you are evaluating a theme, install it in a copy of your dashboard, pick one engine, apply it at profile level, and then look at the cards you actually use.

Editorial conclusion

Frosted Glass suits a Home Assistant user who wants a translucent dashboard and is willing to install a styling engine and apply the theme at profile level. It does not suit an installation that must not run a frontend module, or a dashboard that has to keep working on an old engine, since the source audit only covers card-mod 4.2.1 and UIX 8.3.1. Before enabling it, read the theme manager section, check which engine you already run, and install only one, then confirm the ha-card variables in your own Markdown cards still produce the result you want rather than the transparent default.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wessamlauf/homeassistant-frosted-glass-themes on GitHub