iconoir: the exports map is the API, and a bare path means regular

One grid, one package name, four package managers

The description is short and the numbers matter: an open-source library with 1600 or more unique SVG icons, designed on a 24 by 24 pixel grid. You can take any individual icon from the website or from the repository, or install the whole pack from npm, where the file gives the command for four package managers side by side:

npm i iconoir

The Yarn, pnpm and Bun equivalents sit in the same table row. Importing an icon is a single line, which is worth noticing because it imports the SVG file itself rather than a component wrapper:

import Iconoir from 'iconoir/icons/iconoir.svg';

So the bare package is essentially the asset directory plus the CSS, and everything with a framework in its name is a separate install. That division is what keeps the root package small, and it is also the thing to internalise before choosing an icon, because the same icon name resolves differently depending on which package you installed.

A bare icons path resolves to regular, solid needs a suffix

The exports map in the manifest is the real API and it has four entries for SVGs. The pattern for icons with any name maps to the regular directory, and the pattern for names ending in -solid maps to the solid directory. The two explicit paths for regular and solid are there as well, along with a pattern for CSS files. The consequence is a naming rule rather than an import switch: ask for iconoir/icons/bell.svg and you get the regular bell, ask for iconoir/icons/bell-solid.svg and you get the filled one. The published files array contains only css and icons, so the framework packages are not part of this package at all, which is consistent with the README sending you to a separate README inside the workspace for each of them.

The CSS route renders icons as a mask on a pseudo-element

There is a route that needs no JavaScript at all, and it is implemented with a stylesheet and a naming rule. You add the CSS file from a CDN, then write a single element with a class:

<i class="iconoir-hand-brake"></i>

The rule is stated as a constraint: the class must always begin with iconoir- followed by the name of the icon, and the names are listed on the website. Behaviourally, the icons are display inline-block and default to the current font size, so they scale with surrounding text without any sizing attribute. The part that matters for customisation is that the icons are added as a mask, and you control them by adjusting the ::before styles of the element. That is a different mental model from an SVG sprite sheet, and it is why the class name and the pseudo-element both have to be exactly right before anything appears.

Four framework packages, each with its own README

The framework support is delivered as four separate packages rather than as one package with peer dependencies. React is iconoir-react, React Native is iconoir-react-native, Vue is published as @iconoir/vue, and Flutter is iconoir_flutter. Each section points at a README inside the repository for details rather than documenting usage at the top level, so the top level file is an index rather than a manual. One naming wrinkle is worth noting for anyone scripting an install: the Vue package is named with a scope while its directory in the workspace is not, so a lookup that maps package names to folders by pattern will miss it. The workspace also holds a solid-specific Vue plugin in its build dependencies, which is where the solid variant reaches Vue users.

Framer, Figma and Xcode each get their own path

Three integrations sit outside the package manager. In Framer, the icons are available through the Insert menu under Graphics, named Iconoir, and you switch between icons from the right sidebar in the editor, which means the design tool holds the library rather than importing it. In Figma the pack is published in the community. On Apple platforms the route is a separate repository, Iconoir-swift, added through Xcode by opening the project, going to File, then Swift Packages, then Add Package Dependency, entering the repository URL, choosing a branch or version and selecting the target. The generated API is the same shape in both UI worlds, with a UIKit image view built from an asUIImage value and a SwiftUI view built from asImage.

The repository ships the website, examples and a naming document

The tree explains how much is generated rather than hand-written. Alongside the icons and css directories sit an iconoir.com directory, so the browsing site lives in the same repository, plus a bin directory holding the build and prepublish scripts, a docs directory, a packages directory for the framework libraries, and an examples directory with three projects: Next, React Native and Vue. Two documentation files sit at the root and are worth reading before you import anything, a NAMING_CONVENTION.md and a CONTRIBUTING.md. There is an analysis_options.yaml, which is the Dart and Flutter linter configuration for the Flutter package, alongside an eslint configuration for the TypeScript side, and editor directories for both Cursor and VS Code. The examples are therefore the closest thing to usage documentation the repository offers.

SVGR turns the SVGs into components, and pnpm holds the overrides

The development dependencies describe the pipeline. The SVGR core and its JSX plugin, plus a Babel plugin whose name says it removes the JSX attribute, are what convert SVG files into framework components, which is why the build can emit React, Vue and Solid output from the same source set. Vite with the Vue plugin, the Solid plugin and a declaration plugin does the bundling, esbuild does the fast work, and tinypool and listr2 are a worker pool and a task list for the build. On top of that sit small utilities the build clearly needs, from-html and to-html for HTML, scule for case conversion and semver for version handling. Finally, pnpm overrides pin three transitive packages, which is the usual way a monorepo stops an upstream release from moving underneath it.

Open Collective funding and two patch releases a day apart

Two housekeeping details. The manifest carries an Open Collective funding entry pointing at the project's collective page, which is how an icon set with no commercial product pays for review time. And the release cadence is fast: v7.12.1 on 2026-08-12, v7.12.0 on 2026-08-11, and v7.11.1 on 2026-06-18, so two patch versions shipped within a day of each other and the last push to main carries the same date as the newer release. The package manager is pinned to pnpm 10.13.1 and the package declares itself an ES module. For a library consumed as raw files, that velocity is mostly harmless, but it is the reason to commit a lockfile rather than tracking a floating version.

Editorial conclusion

iconoir fits a project that wants one icon set across a web app, a design file and a native client, since the same SVGs back the npm package, the CSS class names, the Figma pack and the Swift package. It does not fit a team that wants every icon weight in the same import, because the solid variants are only reachable through a filename suffix rather than a separate entry point. Before you adopt it, check four things: whether the naming convention document matches how your team already names things, since icon names become CSS class names and component names, that the framework package you need is published rather than only present in the workspace, whether your build can consume the CSS mask approach if you take that route instead of the components, and which icon variant your design calls for, since a bare path resolves to the regular set.

Frequently asked questions

Official sources

1. iconoir-icons/iconoir on GitHub
2. License: MIT
3. Project website
4. README
5. Releases