# react-icons: One Import Path for Twenty Icon Sets in React

> react-icons bundles icons from Font Awesome, Material Design, Lucide, Simple Icons and others behind per-pack subpath imports. It is a convenience layer, not an icon design system, and the trade-offs show up in bundle size and licence files.

**react-icons/react-icons** — svg react icons of popular icon packs

- Repository: https://github.com/react-icons/react-icons
- Website: https://react-icons.github.io/react-icons/
- Stars: 12,670 · Forks: 809
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/react-icons-react-icons

## The problem react-icons solves for React teams

A React project that needs a beer icon, a weather glyph and a brand mark normally pulls in three separate packages, each with its own import convention, its own peer dependency range and its own release cadence. react-icons collapses that into one dependency. The README describes the project as a way to "include popular icons in your React projects easily" using ES6 imports, and the icon table lists twenty-plus libraries in one place, from Font Awesome 5 and 6 to Material Design, Lucide, Simple Icons, Bootstrap Icons and Game Icons.

The audience is narrow and practical: React developers who treat icons as decoration or UI furniture rather than as a designed system. If your team already standardised on a single icon set with a Figma library and a naming convention, react-icons adds a second source of truth. If you are assembling an internal dashboard, a marketing page or a prototype and you want to reach for whichever glyph fits, the single dependency is the point.

## How the per-pack subpath imports actually work

Each upstream icon library gets its own subfolder under the react-icons package, and you import from that subfolder. The README states this directly: "each Icon package has it's own subfolder under react-icons you import from", and gives Material Design as the example, `import { ICON_NAME } from 'react-icons/md'`. Font Awesome is `react-icons/fa`, Lucide is `react-icons/lucide` by the same pattern.

That structure means the import specifier tells you which upstream set an icon came from, and it means a bundler can be pointed at a single subpath instead of the whole package. What the README does not spell out is what sits inside those subfolders. The repository layout shows a `packages/` directory and a Lerna configuration at the root, so the published artifact is assembled from multiple workspace packages rather than hand-written. Whether your bundler tree-shakes an unused icon out of `react-icons/fa` depends on how that generated entry point is written and on your bundler's settings, not on anything react-icons documents. Treat the phrase "include only the icons that your project is using" as a claim about the import syntax, and verify the emitted bundle yourself.

## Installing react-icons and rendering a first icon

The README gives two package managers for the standard modern project. Either command adds the dependency to your project.

```bash
yarn add react-icons
# or
npm install react-icons --save
```

After that, import a named icon from the subfolder of the pack you want and render it like any other component. The README's own example uses Font Awesome's beer icon inside a heading.

```jsx
import { FaBeer } from "react-icons/fa";

function Question() {
  return (
    <h3>
      Lets go for a <FaBeer />?
    </h3>
  );
}
```

What you should see is the beer glyph rendered inline in the heading. The icon is an SVG component, so it inherits `currentColor` and the surrounding font size unless you override them. To pull from a different pack, change only the path: Material Design icons come from `react-icons/md`, and the README notes the same pattern applies to every pack.

There is a second install path for projects that need finer control. The README offers `@react-icons/all-files`, installed the same way, with one file per icon.

```bash
npm install @react-icons/all-files --save
```

```jsx
import { FaBeer } from "@react-icons/all-files/fa/FaBeer";
```

Be careful here. The README carries a note that this option "has not had a new release for some time" and links to issue 593, and it warns that installation takes a long time because of the file count. The README also lists this path under "meteorjs, gatsbyjs, etc", which reads as legacy framing rather than a recommended default.

## Where react-icons is the wrong tool

The clearest limitation is the second install path. If your build needs one file per icon so that a single unused glyph cannot reach the bundle, `@react-icons/all-files` is the option the README points to, and the same README says it has not had a new release for some time. You are choosing between a package the project still describes as current and a package it describes as stale. Neither choice is free.

The second limitation is licensing. The icon table gives a licence per upstream library, and they do not agree: Font Awesome 5 and 6 are CC BY 4.0, Material Design and Remix Icon are Apache License Version 2.0, Typicons is CC BY-SA 3.0, Weather Icons is SIL OFL 1.1, Simple Icons is CC0 1.0 Universal, Lucide is ISC, and several others are MIT. The root package.json declares `"license": "MIT"` for the workspace, and the repository's own licence field is reported as NOASSERTION. Those two facts do not describe the same thing. The MIT declaration covers the wrapper code; the glyphs you ship carry the terms of whichever upstream pack you imported. A product that cannot accept CC BY attribution requirements should not import from `react-icons/fa` without checking the upstream licence first.

The third limitation is design coherence. Twenty-plus packs in one dependency means twenty-plus stroke weights, grid sizes and corner radii. A screen that mixes `react-icons/fa` with `react-icons/lucide` will look like it was assembled from two different products, because it was. react-icons does not normalise the artwork; it re-exports it.

## How react-icons compares with importing the icon sets directly

The real alternative is not another aggregator. It is installing the upstream package you actually want, such as `lucide-react` or `@heroicons/react`, and importing from it directly. The difference in approach is who owns the version pin. With react-icons, the versions of every bundled pack are decided by a react-icons release: the icon table lists exact upstream versions, so Font Awesome 6 sits at 6.5.2 and Bootstrap Icons at 1.11.3 at the time of that table. You get one version to upgrade, and you get every pack's version moved by the same release.

Importing upstream directly inverts that. You upgrade Lucide when you want Lucide, and a Font Awesome major version bump never touches your Lucide imports. You also get the upstream project's own tree-shaking story, its own documentation and its own issue tracker, rather than a subpath that react-icons generates.

The cost of the direct route is duplication: three icon languages means three dependencies, three upgrade schedules and three sets of peer constraints. That is exactly the overhead react-icons removes. The trade is real in both directions, and the deciding question is whether your icon set is stable. If it is, direct imports give you tighter control. If you are still choosing, or you need brand marks from Simple Icons alongside UI glyphs from Material Design, the aggregator earns its place.

## Maintenance signals and upgrade cost

The repository was last pushed on 2026-09-18 and is not archived, so it is being worked on. The release history is uneven in a way worth reading: v5.6.0 landed on 2026-03-02, v5.7.0 on 2026-06-30, and v6.0.0-beta.0 on 2026-08-12. A beta major means the next stable line is in progress, and the README's own note about `@react-icons/all-files` suggests the per-file variant is not tracking that progress.

Upgrade cost is dominated by icon names, not API. Icons are exported as named symbols, so a rename upstream becomes a compile error in your code, which is the good case. The bad case is a glyph that disappears from a pack entirely and leaves a blank space with no error, because the component still resolves. The root package.json pins a long list of transitive dependencies under `resolutions`, including `esbuild` at 0.28.1 and `glob` at 13.0.6, which tells you the build is managed centrally and that a version bump can move several tools at once. The root scripts expose `yarn lint`, `yarn format` and a Lerna-backed `yarn version-up`, so the project's own release flow runs through Lerna 9.0.7.

On licensing, the practical step is to read the licence column of the icon table for the packs you import and confirm the terms against your own distribution model. That is a reading task, not a legal one, and this article is not legal advice.

## Conclusion

Adopt react-icons when you need several icon languages in one React codebase and want imports such as react-icons/fa or react-icons/md without wiring each upstream package yourself. Do not adopt it if you need per-icon tree shaking at the file level, or if your product cannot accept the mixed licence terms of the bundled packs. Before committing, check the licence column of the icon libraries you actually import, and confirm whether your bundler resolves the barrel files in packages/* the way you expect.

## FAQ

### How do I install react-icons?

The README gives `yarn add react-icons` or `npm install react-icons --save` for a standard modern project. A second option, `@react-icons/all-files`, is available for projects that need one file per icon, but the README notes it has not had a new release for some time.

### How do I use react-icons in a React component?

Import a named icon from the subfolder of the pack you want, for example `import { FaBeer } from "react-icons/fa"`, then render it as a JSX component. Each icon package has its own subfolder under react-icons, so Material Design icons come from `react-icons/md`.

### How do I use react-icons with Font Awesome?

Import from the `react-icons/fa` subpath, as in the README example `import { FaBeer } from "react-icons/fa"`. The icon table lists Font Awesome 5 and Font Awesome 6 as separate entries, both under CC BY 4.0.

### How do I install react-icons in a Next.js project?

The README does not give Next.js-specific steps. The standard install it documents is `yarn add react-icons` or `npm install react-icons --save`, after which you import named icons from a pack subfolder such as `react-icons/fa`.

### How do I use react-icons with TypeScript?

The README does not document a TypeScript-specific workflow. The project is written in TypeScript and the usage example is the same named import from a pack subfolder, for example `import { FaBeer } from "react-icons/fa"`.

## Sources

- [Issues](https://github.com/react-icons/react-icons/issues)
- [Project website](https://react-icons.github.io/react-icons/)
- [react-icons/react-icons on GitHub](https://github.com/react-icons/react-icons)
- [README](https://github.com/react-icons/react-icons/blob/master/README.md)
- [Releases](https://github.com/react-icons/react-icons/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/react-icons-react-icons