Home Assistant Icons: The Best Icon Packs and Integrations for 2026

A dashboard is read, not studied. The quickest way to make one readable is to spend an hour on the icons rather than another hour stacking up cards — a light that looks like a light, a Philips Hue bulb that actually carries the Hue mark, three smart plugs that don’t all render as the same anonymous dot. Home Assistant icons are also the safest thing on the whole system to customise: they are purely presentational, so nothing about how an entity behaves depends on which glyph you choose. This guide covers the icon sets worth installing in 2026, the prefixes you need to type to reach them, the precedence rules that explain why a change sometimes appears in one place and not another, and the licensing details that matter if you publish your configuration publicly.

Quick picks

PickBest forCost
Material Design IconsEverything the built-in defaults already coverFree (bundled with Home Assistant)
Custom Brand Icons (HACS)Real brand and device logos — Philips Hue, Sonos, Tesla, ZigbeeFree, requires HACS
[Font Awesome for Home Assistant](https://www.amazon.co.uk/s?k=Font+Awesome+for+Home+Assistant) (HACS)Extra solid, regular and brand glyphs via fas: / far: / fab:Free tier; Pro tiers paid via fontawesome.com/plans
Mushroom Cards (HACS)Modern icon-led dashboardsFree (card renderer, not an icon pack)
Custom SVG icons (/config/www/)Anything no library stocksFree

If you want one quick win, start with Custom Brand Icons; if you want the single biggest visual upgrade for the least effort, layer Mushroom Cards on top of whatever icon set you run. Together they cover the large majority of dashboards without a penny spent.

How Home Assistant icons work

Every entity in Home Assistant carries an icon attribute, and integrations set sensible defaults — lights get mdi:lightbulb, media players get mdi:speaker, and so on. Icons are purely presentational: they change nothing about how an entity behaves, which is exactly why they are one of the safest things to customise on a live system.

You will see them in entity rows, badges, the logbook, automation traces, the energy dashboard, and in the sidebar if you have customised it. Custom icon sets work by extending the pool of names the frontend can resolve, so mdi:lightbulb can become phu:go or fas:fa-lightbulb without anything else about the entity changing.

The MDI base layer

Home Assistant bundles the full Material Design Icons library, referenced with the mdi: prefix. According to the Pictogrammers project documentation at pictogrammers.com/library/mdi/ — the primary source for this set, checked for this guide in 2026 — the library has grown to approximately 7,400 glyphs, released under the permissive Apache 2.0 licence. That permissive licence is why it ships by default rather than as an optional add-on, and it is also why you can publish configurations containing MDI names without legal anxiety.

The exact version bundled with the frontend moves with each Home Assistant release; the 2025.x releases shipped a 7.x build, for example, so the figure in your own instance depends on the release you are running. Check your release notes if a glyph you expect is missing. Naming is descriptive and consistent: mdi:washing-machine, mdi:ev-station, mdi:solar-power, mdi:heat-pump, mdi:battery-charging-70.

Where the default set falls short

Three complaints recur in community feedback and owner reviews. First, no brand marks — there is no Hue logo, no Sonos logo, no Zigbee or Z-Wave logo, so a dashboard full of branded hardware all looks generic. Second, thin coverage in niche categories: heat pumps, EV chargers, inverters, water softeners and some regional appliance types have fewer options than mainstream categories, so you end up with several visually similar choices rather than one exact match. It is worth correcting a myth here — mdi:heat-pump, mdi:ev-station and mdi:solar-power do exist. The real gap is variety and brand specificity, not absence. Third, visual repetition: if you own three smart plugs, all three render identically, and on a wall-mounted tablet that becomes genuinely confusing.

The prefix cheat-sheet

Every icon set you add registers its own prefix. Only one of them is built in.

PrefixSource collectionRequires HACS
mdi:Pictogrammers MDI (built-in)No
si:Simple Icons, via custom-brand-iconsYes
phu:custom-brand-icons Hue device setYes
fas: / far: / fab:hass-fontawesome frontend moduleYes

These prefixes only work in contexts that resolve the registered frontend resource. In practice that means customize: YAML, a card’s icon: key, and custom:[button-card](https://www.amazon.co.uk/s?k=button-card) all accept them — but the logbook and the energy dashboard do not. Those surfaces use the integration’s device_class defaults and ignore custom prefixes entirely, no matter what you type.

Icon precedence: why your change didn’t appear everywhere

Home Assistant resolves an entity’s icon from lowest to highest priority:

  1. The integration’s device_class default
  2. A customize: block in configuration.yaml
  3. A card-level icon: key

A customize: change propagates to entity rows and badges, but not to logbook entries, because the logbook reads the device_class default rather than your override. That single rule explains most of the “I changed the icon and half the dashboard ignored me” reports in community threads.

The icon packs, reviewed

Material Design Icons — the built-in baseline

Best for: anyone whose entities the defaults already cover, and anyone who wants zero maintenance. Cost: free.

Nothing to install, no HACS dependency, no risk of breaking during a Home Assistant update. It works everywhere an icon: key is accepted, including customize: blocks in configuration.yaml, badges, custom:button-card and scripts. In practice, the built-in set covers the large majority of a typical dashboard — commonly estimated at somewhere around 70–80% — so if MDI already covers your entities, you do not need anything else.

Caveat: its limit is scope, not quality. No logos, no brand marks, and comparatively few options for niche appliance categories.

Verdict: install nothing, change nothing, and check whether this alone solves your readability problem first.

Where to get it: it ships with Home Assistant. Nothing to buy — browse the glyph set at pictogrammers.com/library/mdi/.

Custom Brand Icons (HACS)

Best for: dashboards full of real-world branded hardware. Cost: free, though it requires HACS.

This is the pack that solves the “everything looks generic” problem, adding marks for Philips Hue, Sonos, Tesla, Zigbee and hundreds more. It registers two prefix families: si:, which pulls in the broad Simple Icons collection, and phu:, a Hue-specific device set covering Hue bulb and fixture shapes.

Caveat: it is a third-party package delivered through HACS, so a Home Assistant or HACS upgrade can occasionally need it reinstalled or updated before your icons return. Keep a backup of your configuration and re-check after major releases.

Verdict: the best free upgrade in the entire category, and the one most people should install first.

Where to get it: the HACS frontend store, or the repository at github.com/elax46/custom-brand-icons, maintained by @elax46.

Font Awesome for Home Assistant (hass-fontawesome)

Best for: extra solid, regular and brand glyphs available under the familiar fas:, far: and fab: prefixes. Cost: free tier, with paid Pro tiers.

The free tier covers roughly 2,000 icons — enough for a dashboard’s worth of generic shapes with the same naming conventions you may already know from web work. It is delivered as a frontend module and registered through HACS, like the other third-party sets here.

The paid side: Font Awesome publishes its plan pricing in US dollars at fontawesome.com/plans across three tiers — Starter, Pro and Business. Converting at the exchange rate current in 2026, the paid tiers typically work out to somewhere around £90–£170 a year depending on tier, so check the live figure before buying, as the pound equivalent moves with the exchange rate. The important practical point is licensing: the Font Awesome Pro licence restricts redistribution, so publishing a configuration containing Pro glyphs to a public GitHub repository may breach its terms. The licence terms are at fontawesome.com/license — read them before you push.

Caveat: Pro is the only paid path in this guide, and the redistribution restriction catches people out precisely because they have paid and assume publication is therefore fine.

Verdict: the free tier is a genuinely useful supplement; the Pro tiers only make sense if you specifically need their glyphs and accept the licence limits.

Where to get it: the free frontend module through the HACS frontend store, or github.com/thomasloven/hass-fontawesome, maintained by @thomasloven. Paid plans at fontawesome.com/plans.

Mushroom Cards — not an icon pack

Best for: modern, icon-led dashboards. Cost: free.

Mushroom Cards belongs in this guide because it is the change people actually notice, but it must be described accurately: it is a card renderer only. It adds zero new icon names and zero new glyphs. What it does is restyle the MDI icons you already have into a cleaner, more consistent, more legible layout — which is often the whole visual upgrade people were chasing, without any new icon set being involved at all.

Caveat: do not install it expecting new icons. It changes how icons are drawn, not which icons exist, so pairing it with Custom Brand Icons or Font Awesome is what produces the finished look.

Verdict: the single biggest visual upgrade for the effort, provided you understand it is a renderer rather than a source of glyphs.

Where to get it: the HACS frontend store, or github.com/piitaya/lovelace-mushroom, maintained by @piitaya.

Custom SVG icons — the sharpest differentiator

Best for: anything no library stocks — a local utility’s logo, a specific appliance model, your own floor-plan markers. Cost: free.

Drop an SVG file into /config/www/ and reference it as /local/filename.svg. There are two routes: the entity_picture: attribute, which needs no add-on at all, or the hass-local-icons frontend plugin, which lets you address your own files with an icon-style prefix. Confirm the plugin’s current maintainer and repository before installing, as that project has changed hands over its life.

Caveat: you supply the artwork yourself, and entity_picture: is not an icon: key, so it behaves slightly differently in layouts — which is precisely what makes it useful for imagery such as logos and floor plans that no glyph font will ever provide.

Verdict: the only route that is genuinely unlimited, and the fix for the last handful of entities nothing else can name.

Where to get it: nothing to buy. Create the file, drop it in /config/www/, and reference it locally.

Template icons — icons that change with state

Best for: entities whose icon should reflect what they are doing — a heat pump running versus idle, a battery charging versus full. Cost: free.

Home Assistant’s templating documentation supports both icon_template: (the legacy form) and icon: with Jinja2 in template entities; the reference is the templating page at developers.home-assistant.io. That lets you write a conditional so the glyph changes with the entity’s state rather than staying fixed.

Caveat: a templating error breaks the entity’s icon rather than throwing an obvious error, so test your template in Developer Tools before relying on it on a wall tablet.

Verdict: the most under-used option in this guide, and free — it adds dynamism that no icon pack can supply on its own.

Where to get it: no installation. It is a core templating feature; see developers.home-assistant.io.

Cache-busting: when new icons don’t appear

New icons and updates are frequently blocked by cached frontend resources rather than by anything you wrote. The fixes differ by surface:

  • Browser: hard-refresh the page.
  • Companion app: Settings → Companion App → Reset frontend cache.
  • Kiosk or wall tablet: follow the icon pack’s own repository troubleshooting notes rather than generic advice, because the correct fix depends on how that pack registers its frontend resource.

UK licensing and practical notes

MDI’s Apache 2.0 licence is genuinely permissive, which is why publishing a configuration full of mdi: and si: names is safe. Font Awesome Pro is the one to watch: its licence restricts redistribution, so a public GitHub repository containing Pro glyphs may breach the terms even though you paid for the licence. And remember that HACS is a community store rather than an official channel — third-party repositories can and do change maintainers, so keep a dated backup of configuration.yaml before any large icon overhaul.

FAQ

How many icons does Material Design Icons actually include? Pictogrammers currently documents approximately 7,400 glyphs, and that count grows over time, so treat it as a snapshot rather than a fixed number. The version bundled with your frontend depends on which Home Assistant release you run — the 2025.x line shipped a 7.x build — so check your release notes if a specific glyph is missing. The authoritative live count is at pictogrammers.com/library/mdi/.

Are any of these icon packs paid? Almost none of them. MDI ships free with Home Assistant under Apache 2.0, Custom Brand Icons is free, hass-fontawesome’s free tier covers roughly 2,000 icons, and Mushroom Cards is free. The only paid path in this guide is Font Awesome’s Pro tiers, published in US dollars at fontawesome.com/plans across Starter, Pro and Business, which typically convert to somewhere around £90–£170 a year depending on tier at the 2026 exchange rate.

Can I publish my configuration publicly if it uses brand icons? Yes for MDI and the Simple Icons set behind Custom Brand Icons, because their licences permit it. No, in most cases, for Font Awesome Pro — its licence restricts redistribution, so a public repository containing Pro glyphs may breach the terms. Check fontawesome.com/license before you push anything containing fas:, far: or fab: names.

Do custom icon prefixes work in the logbook and energy dashboard? No. Those surfaces use the integration’s device_class defaults and ignore custom prefixes entirely. That is why a customize: override shows up on entity rows and badges but leaves logbook entries unchanged — the two are reading from different sources.

Do I need HACS to use any of this? Only for the third-party sets. mdi: is built in and needs nothing. si:, phu: and the fas: / far: / fab: family all require HACS to install the frontend module that registers them. Custom SVG files and template icons need neither.

How do I add my own logo or a picture of my actual device? Drop an SVG into /config/www/ and reference it as /local/filename.svg, either through the entity_picture: attribute or via the hass-local-icons frontend plugin — check that plugin’s repository for its current maintainer before installing. This bypasses icon libraries entirely, which is why it is the only approach that is genuinely unlimited.

Will my custom icons survive a Home Assistant update? Built-in mdi: icons always survive, since they ship with the frontend. Third-party sets delivered through HACS can occasionally need updating or reinstalling after a major release before their prefixes resolve again. If your dashboard reverts to default glyphs after an upgrade, check HACS first and reset the frontend cache second.

The bottom line

Start with what is already there: Material Design Icons covers the large majority of a typical dashboard at no cost and with no maintenance. Add Custom Brand Icons when the absence of real-world logos becomes the thing you notice, and add Mushroom Cards when you want the layout itself to look sharper — remembering that it restyles rather than supplies icons. Reach for hass-fontawesome if you need extra solid or brand glyphs and can live with its licence terms, drop in a custom SVG for the last few entities nothing else names, and use template icons for the ones whose meaning changes with state. That combination, in that order, is the whole job.