Hugeicons: one icon set shipped as separate packages for each framework

Renderers and icons are separate packages

The most useful thing to understand about Hugeicons before installing anything is that the framework libraries and the icon data are separate packages.

The framework libraries are renderers. The icons themselves come from either `@hugeicons/core-free-icons` with 6,000+ icons, or from the Pro packages `@hugeicons-pro/core-*` with 60,000+ icons across 10 styles.

That split is what makes the tree-shaking claim work. The feature list calls the packages tree-shakeable, ship only the icons you use, and the mechanism is that the icon catalogue is a module of named exports rather than a bundled blob, so a bundler can drop the ones you never import.

The React quick start shows the shape:

import { HugeiconsIcon } from '@hugeicons/react';
import { SearchIcon } from '@hugeicons/core-free-icons';

function App() {
  return (
    <HugeiconsIcon
      icon={SearchIcon}
      size={24}
      color="currentColor"
      strokeWidth={1.5}
    />
  );
}

The `icon` prop takes the icon data itself, not a string name. That is why the icon import is a separate package, and it is also why the framework package is small: it renders whatever shape data it is handed, and it does not know what icons exist.

Note `color="currentColor"`, which inherits the text colour from the parent, and `strokeWidth`, which is relevant because the stroke style is the default for the free set. The `size` prop is 24 in the example, matching the grid the icons are drawn on.

The install command for every web framework follows the same two package pattern, for example `npm i @hugeicons/react @hugeicons/core-free-icons`, with React Native adding `react-native-svg` and Flutter using `flutter pub add hugeicons`.

Ten styles, and what the free set actually includes

The catalogue is organised around a 24x24 grid, and the grid is a real constraint rather than a slogan.

Every icon is hand-crafted for consistency, clarity, and balance, so your interface looks sharp at any size, in any style. The claim is pixel-perfect, built on a 24x24 grid for crisp rendering at any scale. What a 24x24 grid buys is that every icon in the set occupies the same optical box, so a row of mixed icons lines up without per-icon nudging, and so a single size value works across the set.

The style list is where the free and paid tiers diverge, and the table is explicit about it.

Free gives you 6,000+ icons in a single style, Stroke Rounded. Pro gives you 60,000+ icons in 10 styles, being Stroke, Solid, Bulk, Duotone and Twotone across rounded, sharp and standard families.

That is a substantial difference in kind, not just in quantity. A set with one style is a set of outline icons. A set with ten is a set where the same glyph can be solid for a filled button, duotone for a hero, bulk for a marketing block, and outline for a menu, which is what makes a design system feel coherent when the same concept appears in different contexts.

Both tiers are for personal and commercial use. The difference is the licence, not the permission. The free icons and all source code in the repository are released under the MIT License, and the Pro icons come under a separate Pro License. The repository is MIT licensed and the free set is described as being for unlimited personal and commercial use.

The upgrade path is stated as open ended. You can upgrade any time, and the Pro catalogue is explored on the pricing page.

Seven framework packages, one design language

The package table is the clearest statement of scope, and it covers more than the usual set.

React is `@hugeicons/react`, Vue is `@hugeicons/vue`, Svelte is `@hugeicons/svelte`, SolidJS is `@hugeicons/solid-js`, Angular is `@hugeicons/angular`, React Native is `@hugeicons/react-native`, and Flutter is published on pub.dev as `hugeicons`.

The description calls them first-class libraries, and the repository structure backs that up. This is a pnpm workspace with a `packages/` directory holding one directory per framework, and a `pnpm-workspace.yaml` and `pnpm-lock.yaml` at the root. The root `package.json` is a private monorepo root, with a build script that recurses with `pnpm -r run build` and matching typecheck, test and clean scripts, and the package manager is pinned to pnpm 10.30.0 with Node 18 or newer required.

The primary language of the repository is Dart, which reflects the Flutter package being a first-class citizen rather than a port. The icons themselves live in an `icons/` directory at the top level, and `assets/` holds the branding and banner.

The pitch for the multi framework support is consistency rather than reach. One design language, available natively wherever you work, so a dashboard in React and a companion app in Flutter share the same icon shapes rather than looking like two products that happened to come from the same team.

Beyond the framework packages there are plugins for the tools where design work actually happens. There is a Figma plugin in the Figma Community, a Framer plugin in the Framer Marketplace, a Webflow app, a WordPress plugin on WordPress.org, and an Elementor plugin that lives in the repository under `plugins/elementor`.

And there is a tool rather than a plugin, an MCP server, `@hugeicons/mcp-server`, whose source is in `tools/mcp-server`.

The agent skill exists to stop names being invented

The `skills/hugeicons` directory holds an agent skill, and the reason it exists is stated in unusually blunt terms.

It gives coding agents like Claude Code, Codex and other AI coding agents accurate, first-party guidance on using Hugeicons, so they stop guessing icon names and props from stale training data.

That is a real problem and a common one. A model asked to use an icon library will produce plausible component names and plausible prop names, and a plausible wrong name is worse than no name because it type checks in a JavaScript project without types and fails at runtime with a blank space in the layout.

The design of the skill is a workflow, and the workflow is detect, install, render, props, applied for React, Vue, Svelte, SolidJS, Angular, React Native and Flutter. One skill covers every framework, and the agent detects which one a project uses and applies the right component, props and icon catalogue.

The catalogue is the important part. The complete icon catalog lives in `references/icon-list.md` for the shared JavaScript exports and `references/icon-list-flutter.md` for the Flutter constants, and the stated rule is that names are copied, never invented. So the skill is a lookup table plus a procedure, and the failure mode it prevents is precisely the one that is hardest to catch in review.

It also carries the commercial guidance, Free versus Pro, plus a minimal-code convention: only pass props that override a default. That last part is a real design opinion rather than a documentation detail, since the React example above passes four props where the defaults might cover most of them.

Installing it is one command from the project root, and the agent picks it up on the next session:

npx skills add hugeicons/hugeicons

The reference to the skills.sh site in the README suggests this follows a convention that other projects are starting to follow, where a package ships an agent-readable skill rather than a human-readable document only.

Where the icon set model gets awkward

The approach has limits, and they are worth naming before you commit a design system to it.

The first is the split between free and paid in a way that can bite. The free set is a single style, Stroke Rounded. The free set ships only the Stroke Rounded style, so a filled variant means moving to Pro even when the icon itself is in the free catalogue. If the concept you need is not in the free set at all, you are into the Pro tier, and the Pro icons carry a different licence from the free ones and the code. For a commercial product that is a procurement conversation, not a technical one, and it is worth settling before the design is signed off rather than after.

The second is that the icon data is a separate package per framework in practice. The React quick start imports from `@hugeicons/core-free-icons` and the Flutter side has its own constants file, `references/icon-list-flutter.md`. That is the cost of not having one package that works everywhere, and it is why the skill needs a Flutter specific reference.

The third is the trap of a very large catalogue. 60,000+ icons sounds like a benefit until a team picks twelve that do not obviously match, which is what happens when there is no single visual language to defer to. A smaller set forces a decision; a huge set defers it. The consistency claim is the answer, and whether it holds for your own product depends on how disciplined the design is about it, not on the catalogue size.

The alternative to an icon set of this size is the smaller, opinionated alternatives that ship a few hundred icons with a strong point of view. The difference in approach is that a small set removes most of the choice and most of the inconsistency risk, at the cost of coverage, so a product that needs a niche concept ends up drawing it by hand, which is work the large catalogue has already done.

There is also the licensing question to be careful about. The free icons and all source code in the repository are MIT, which permits use, modification and redistribution, and the Pro icons sit under the Pro License. The description at the top of the repository is about consistency and craft rather than about the licensing, so read `LICENSE.md` and the Pro licence agreement directly if you are redistributing icons inside a product, rather than relying on a summary.

On maintenance, the last push was on 2026-10-15, the repository is not archived, and there are no GitHub releases, since the packages are versioned on npm and pub.dev instead. The documentation says new icons are added regularly, and the free and Pro counts are stated in the same table, so the catalogue grows on both sides.

Editorial conclusion

Hugeicons fits a team building in more than one framework, or a team that wants one icon language across a web app, a design tool and a mobile app, because the icons are the same assets in each case and the packages are thin renderers over them. Skip it if a single framework package and a handful of icons is all you need, since the extra packages and the icon catalogue are real dependencies to think about, and read the licensing split carefully if you are shipping commercially, because the free set is MIT while the Pro set is under a separate Pro licence. Before you adopt it, run `npx skills add hugeicons/hugeicons` and let the agent skill supply exact icon names, since the alternative is an agent inventing prop and icon names that do not exist. The last push was on 2026-10-15.

Frequently asked questions

Official sources

1. hugeicons/hugeicons on GitHub
2. Issues
3. License: MIT
4. Project website
5. README