ng-icons puts dozens of icon sets behind one Angular component
The ultimate icon library for Angular
At a glance
- What is it?
- ng-icons is an Angular library that serves more than 116,500 icons from dozens of different sets through a single component, with each set published as its own package. The core is MIT, but the icon sets carry their own licences, from MIT and CC0 through Apache 2.0, MPL 2.0, CC BY-SA and one custom licence, which makes the dependency list something to read rather than skim.
- Who is it for?
- ng-icons suits an Angular team that wants one component API across several icon libraries instead of several components, and the per-set packages mean you only install the sets you use. It is the wrong choice for a project outside Angular, for a team that has to ship one licence across the whole bundle, and for anyone still supporting browsers outside the evergreen set.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One component instead of one component per library
ng-icons describes itself as the all-in-one icon library for Angular, and the mechanism is a single icon component. The README states that this allows you to use icons from multiple icon sets with a single icon component, and that it contains over 116,500 icons.
That number is a sum of many libraries rather than one design, and the set list shows what is included. Among them are Bootstrap Icons, Heroicons, Ionicons, Material Icons, Material File Icons, CSS.gg, Feather Icons, Jam Icons, Octicons, Radix UI Icons, Tabler Icons, Akar Icons, Iconoir, Cryptocurrency Icons, Simple Icons, Typicons, Dripicons, UX Aspects, Circum Icons, Remix Icon, Font Awesome, Iconsax, TDesign Icons, Phosphor Icons, Lets Icons, Huge Icons, Devicon, Game Icons, Flag Icons, Solar Icons, SVGL, Material Symbols, MynaUI, Boxicons, Mono Icons, Lucide Icons, Coolicons, Fluent UI, PrimeIcons, Keyline Icons and Reicon.
The reason to care about the count is not the count. It is that the component API is the same whatever the source, so a design system can mix a Feather arrow with a Phosphor logo and a Flag country marker without the template changing shape.
The project also documents an entry point for contributing: create an issue if you want an additional icon set and the maintainers can consider adding it. The documentation site carries the introduction, a browse page and a list of icon sets.
The licence you inherit depends on the icon set
The package table is the most consequential part of the README, because the core licence and the icon set licences are not the same thing.
The core package, @ng-icons/core, is MIT, and so are most of the set packages, including Bootstrap Icons, Heroicons, Feather Icons, Tabler, Phosphor, TDesign, Devicon, SVGL, MynaUI, Boxicons, Mono Icons, Lucide, Material File Icons, CSS.gg, Jam, Octicons, Radix, Akar, Iconoir and the crypto set in its MIT packaging.
The exceptions are the interesting part. @ng-icons/material-icons, @ng-icons/ux-aspects, @ng-icons/remixicon and @ng-icons/material-symbols are Apache 2.0. @ng-icons/cryptocurrency-icons and @ng-icons/simple-icons and @ng-icons/huge-icons are CC0-1.0. @ng-icons/typicons and @ng-icons/dripicons are CC-BY-SA-4.0. @ng-icons/circum-icons is MPL-2.0. @ng-icons/font-awesome is CC BY 4.0, @ng-icons/game-icons is CC BY 3.0, @ng-icons/solar-icons is CC BY 4.0, @ng-icons/lets-icons is CC-BY-4.0, and @ng-icons/iconsax is under a custom licence linked from the iconsax site.
Three of those deserve a second look in a compliance review. MPL-2.0 is file level copyleft, so it attaches to the files it covers rather than the whole bundle. The CC BY-SA sets are share alike, so an adapted icon has to be released under the same terms. And a custom licence is by definition the one you most need to read.
None of that makes the library unusable. It makes the licence audit per set rather than per project, which is why the table is worth reading before you install, not after.
Install the core and only the sets you use
The installation section is explicit that you must install the @ng-icons/core package, and that you only need to install the iconset libraries you intend to use.
With npm:
npm i @ng-icons/core @ng-icons/heroicons ...Or with yarn:
yarn add @ng-icons/core @ng-icons/heroicons ...The trailing ellipsis in both examples is the important part. It stands for the additional set packages you want, each of which is published under the @ng-icons scope with a name derived from the upstream library, such as @ng-icons/heroicons or @ng-icons/tabler-icons.
That packaging choice is the practical advantage over installing several icon libraries directly. Each set arrives as a separate package, so the ones you do not use never reach your node_modules, and the icon data for a set you do use is not pulled into your bundle because of a library you happen to have installed for a different project.
The trade is that you make the choice at install time rather than at build time, so a set that appears in a design late in the project needs a dependency change and a reinstall.
Version numbers track the Angular release
The supported versions table maps Angular versions to ng-icons versions, and it is a long one. Angular 11.x works with ng-icons 12.x, 12.x with 12.x through 13.x, 13.x with 13.x through 17.x, 14.x with 17.x through 22.x, 15.x with 23.x through 24.x, 16.x with 25.x, 17.x with 26.x through 27.x, 18.x with 28.x through 29.x, 19.x with 30.x through 31.x, 20.x with 32.x, 21.x with 33.x through 34.x, and 22.x with 35.x.
The pattern is that a major version of ng-icons lands alongside an Angular major, with the minor releases in between serving the versions in between. In practice that means an Angular upgrade usually implies an ng-icons upgrade, and the two are versioned together rather than independently.
The browser floor is stated just below the table, and it is a hard one. Ng Icons relies on modern browser features and is designed to work on evergreen browsers. The project does not support older browsers such as IE11.
So an application still expected to run on an older browser cannot use this library, and an application that upgrades Angular every few months will find the ng-icons version tracking its own release cycle rather than the other way round.
An Nx monorepo that generates its own icon packages
The repository is an Nx workspace, and the build pipeline explains how thousands of icons become typed Angular packages.
The top level has nx.json, project.json, a packages/ directory, an apps/ directory, a tools/ directory and a tsconfig.base.json, with pnpm-lock.yaml for the workspace and vitest.config.ts for the tests. The scripts in package.json are the Nx ones: nx serve documentation for the docs site, nx run-many for lint and test, and a compile step that first runs the svg-to-ts generator and then the readme updater before building every package:
"compile": "nx generate @ng-icons/workspace-plugin:svg-to-ts && nx generate @ng-icons/workspace-plugin:update-readmes && nx run-many --target=build --all --parallel=8",The workspace plugin is the interesting piece. Icons are converted from SVG into TypeScript by a generator that runs inside the workspace, which is why the upstream SVG sources are dependencies of the root package.json, including @ng-icons/svgs pulled from its own repository and the SVGL collection pinned to a specific commit.
The publishing flow follows the same shape, with nx release versioning and changelog steps before the compile and the publish. There is a .verdaccio directory, which points at a local registry for testing package installs before they go out, a husky setup for git hooks, and a flat eslint config. CHANGELOG.md and MIGRATION_GUIDE.md sit at the root, which is where you look before an upgrade.
Where ng-icons is the wrong choice
Three situations rule this library out, and they are worth checking before you install.
It is an Angular library, so a React, Vue or plain web project has no use for it. The component, the package layout and the generator pipeline are all Angular specific.
It assumes evergreen browsers. If your application has to run on anything older, the library will not help you, and the version matrix does not change that.
And the licence picture has to be settled before install, not after. If your organisation has a rule that everything shipped in a bundle must be under one permissive licence, then the CC BY-SA sets, the MPL-2.0 set and the custom licence for Iconsax are obstacles, and the answer is to use the sets whose row in the package table is MIT or Apache 2.0. A library that ships forty sets is a convenience, and convenience and a single licence policy do not always agree.
There is also a bundle consideration that the packaging only partly solves. The whole point of separate set packages is that unused sets cost nothing, but the set you do use is a large body of icon data, and the library does not describe a tree-shaking story for it in the README.
Maintenance, releases and how to consume it safely
The repository is not archived, and the last push was on 2026-10-01. The recent releases are v36.1.0 on 2026-09-25, v36.0.0 on 2026-09-02 and v35.1.0 on 2026-08-27, which matches the support table where Angular 22.x pairs with the 35.x line and the newer work sits in the 36.x line.
The project is MIT licensed as a whole, with ongoing development made possible by contributors and sponsors, and the README links a sponsor page for the maintainer.
Two habits will keep you out of trouble. The first is to read the version matrix before you upgrade Angular, because the ng-icons major is decided for you and the two are not independently versioned. The second is to read MIGRATION_GUIDE.md before you upgrade ng-icons, since a library that regenerates packages from upstream SVG sources can change the shape of an individual icon between minors, and the guide is where those changes are recorded.
For a team, the practical sequence is short: install the core plus the sets your design uses, check the licence row for each of those sets, and keep the set packages pinned in your lockfile so a new release cannot quietly change which icons your product ships.
Editorial conclusion
ng-icons suits an Angular team that wants one component API across several icon libraries instead of several components, and the per-set packages mean you only install the sets you use. It is the wrong choice for a project outside Angular, for a team that has to ship one licence across the whole bundle, and for anyone still supporting browsers outside the evergreen set. Verify first which icon sets your design actually uses, check the licence row for each of those sets in the package table, and read MIGRATION_GUIDE.md before upgrading, because the version numbers in the support matrix move with the Angular release and the library's major version tracks it.
Frequently asked questions
How do I install ng-icons and only the icon sets I need?
Install @ng-icons/core plus the packages for the sets you intend to use, for example npm i @ng-icons/core @ng-icons/heroicons. The README is explicit that you only need to install the iconset libraries you intend to use, and each set is published as its own package under the @ng-icons scope.
Which licence applies to the icons in ng-icons?
The core package is MIT, but each icon set package carries its own licence. The package table shows MIT for most, Apache 2.0 for material-icons, ux-aspects, remixicon and material-symbols, CC0-1.0 for cryptocurrency-icons, simple-icons and huge-icons, CC-BY-SA-4.0 for typicons and dripicons, MPL-2.0 for circum-icons, and a custom licence for iconsax.
Which Angular versions does ng-icons support?
The README maps Angular versions to ng-icons versions, from Angular 11.x with ng-icons 12.x up to Angular 22.x with ng-icons 35.x, with several Angular versions served by a range of ng-icons releases in between. A new ng-icons major generally lands with a new Angular major.
Does ng-icons work in older browsers such as IE11?
No. The README states that Ng Icons relies on modern browser features, is designed to work on evergreen browsers, and that older browsers such as IE11 are not supported.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/ng-icons-ng-icons)Was this useful?