CoreUI Icons: 1500 free glyphs, three licences and one stray attribution

One package, three licences, and a metadata field that lies by omission

The single most important fact about CoreUI Icons is that it is not one licensed thing. The License section splits it three ways, and the split is by file type rather than by component.

Icons are CC BY 4.0, and in the free set that licence applies to all icons packaged as .svg and .js files. Fonts are SIL OFL 1.1, applying to icons packaged as web and desktop font files. Everything else, described as non-font and non-icon files, is MIT. Brand and flag icons sit under a separate heading and are released under CC0 1.0 Universal.

That structure has a consequence for tooling, and it explains the repository's own metadata. package.json declares "license": "MIT", which is true of the code and false of the majority of what a consumer actually ships. The repository-level licence field reads as a custom licence GitHub cannot classify, and that is the classifier being accurate rather than confused: there is no single SPDX identifier for CC BY 4.0 plus SIL OFL 1.1 plus MIT in one artifact. The README is unusually clear about the free set being for commercial projects, open source projects, or almost whatever you want, and calls it GPL friendly.

The obligation that is easy to miss is the CC BY 4.0 one. Using the SVG files or the JavaScript files means the icons are covered by a Creative Commons Attribution licence, which asks you to credit the creator. The webfont route is under OFL and does not carry the same attribution requirement in the same form. So the delivery format you choose changes your obligations, which is not how most teams expect an icon package to behave.

The brand icon terms name a different project

Under CoreUI Icons Brand and Flag Icons, the Brand Icons subsection contains a paragraph that should not be there.

The text reads: All brand icons are trademarks of their respective owners. The use of these trademarks does not indicate endorsement of the trademark holder by Font Awesome, nor vice versa. Please do not use brand logos for any purpose except to represent the company, product, or service to which they refer.

This repository is CoreUI Icons, not Font Awesome. The paragraph is carried over legal boilerplate, and the practical question for a reader is which half of it applies. The two sentences that matter are unaffected by the error. Trademark belongs to the respective owners regardless of which icon set drew the glyph, and the restriction on using a brand logo for anything other than representing the company, product or service it refers to is a rule about trademarks, not about the drawing. The Copyright line that follows is the standard CC0 statement of purpose, which is the part that makes the glyphs themselves free of copyright claims while leaving trademark untouched.

So the usable summary is: brand glyphs are CC0 as artwork, restricted as marks. A cib-twitter glyph carries no copyright encumbrance on the file, and you still may not use it to imply something the mark's owner did not say. That is the normal position for any icon set with brand coverage, and the naming slip does not change it, but it does mean the paragraph in front of you is not this project's own legal text and should be read as a starting point rather than as an authoritative statement.

The practical consequence for a product: the free, brand and flag glyphs are three separately licensed populations inside one package, and the flag set in particular is a set of national and regional symbols where accuracy and currency both matter.

cil-, cib- and cif- decide which stylesheet you ship

The naming scheme is the whole API for the common case, and it is three prefixes rather than one.

Linear icons use the cil- prefix, brand icons use cib-, and flag icons use cif-. The icons are designed for inline elements such as an i or a span, and the class name is the icon's name:

<i class="cil-energy"></i>
<i class="cib-twitter"></i>
<i class="cif-us"></i>

Because the class carries both the family and the name, you can tell at a glance in your markup which set an icon came from, which matters when you later decide to drop the brand bundle.

The stylesheet choice is the part with a real cost, and the README offers two shapes. The short one:

<link rel="stylesheet" href="https://unpkg.com/@coreui/icons/css/all.min.css">

The other lists the three sets separately:

<link rel="stylesheet" href="https://unpkg.com/@coreui/icons/css/free.min.css">
<link rel="stylesheet" href="https://unpkg.com/@coreui/icons/css/brand.min.css">
<link rel="stylesheet" href="https://unpkg.com/@coreui/icons/css/flag.min.css">

The concat step in the build script names the three inputs as css/free.css, css/brand.css and css/flag.css, so all.min.css is those three combined. If your product uses a dozen linear icons and no brand marks, the single-file version hands you the brand and flag sets as well, and the second version is what the build is shaped to support.

For npm and yarn users the install is unremarkable:

npm install @coreui/icons --save
yarn add @coreui/icons

The package also supports a GitHub clone or a zip download, so the package manager is optional rather than required.

Sprites and symbols skip the font entirely

The webfont is one option and the SVG options are two more, and the SVG routes are the ones that avoid loading a font file at all.

The sprite route uses the prepared sprite files, which the project describes as each icon set style in its own SVG sprite. You place them alongside your other static files, and you reference an icon by fragment identifier:

<svg>
  <use xlink:href="path/to/free.svg#cil-airplane-mode"></use>
</svg>
<svg>
  <use xlink:href="path/to/brand.svg#cib-twitter"></use>
</svg>
<svg>
  <use xlink:href="path/to/flag.svg#cif-us"></use>
</svg>

The symbol route is the same idea with the definitions inlined. A downloaded icon set arrives with a sprites directory containing the SVG icon definitions, and the README shows a full symbol with a viewBox of 0 0 24 24, a title element and the complete path data, followed by a use element pointing at the local id. The path data is inlined rather than referenced so the definition is self-contained, which means the markup you paste is large and the README's example is genuinely what you get.

You can also point at an external file rather than inlining, and the README gives that variant with a class on the svg element so you can size it in CSS:

<svg class="icon-home">
  <use xlink:href="path/to/free.svg#cil-apple"></use>
</svg>

The practical difference between the three delivery modes is where the bytes and the control live. A webfont is one file and a class name, and it inherits everything the font file carries. An external sprite is one request per set and gives you the vector under CSS control. An inlined symbol is zero requests and a large block of markup per icon. Which one is right depends on whether you have a hundred icons on a page or a thousand routes, and the README does not take a position on it.

css/ and fonts/ are committed, so npm install does not build

The repository contains build/ , scss/, css/, fonts/, sprites/, svg/ and src/ at the top level, alongside package.json, package-lock.json and three TypeScript configuration files named tsconfig.base.json, tsconfig.cjs.json and tsconfig.esm.json. The presence of a committed css/ directory is the fact with the most consequence.

The build script makes the pipeline explicit. npm run build runs clean, then css, then rollup in sequence. The css step compiles the two stylesheet compilations in parallel, then applies prefixes, then concatenates, then minifies. Compilation is sass from scss/ into css/ with expanded style and source maps, prefixing is postcss with a config at build/postcss.config.mjs, concatenation joins free.css, brand.css and flag.css into all.css, and minification is cleancss writing suffixed .min files with rebased inline source maps. The JavaScript side is a single rollup run against build/rollup.config.mjs.

So a consumer installing @coreui/icons receives already-built CSS and already-built fonts. Nothing compiles at install time, and the stylesheet you link to exists in the tarball. For a consumer that is good news: the CDN file and the npm file are the same artifact, so behaviour does not change when you move between them. For a fork, it means the generated output is versioned and your diff will contain CSS and font changes alongside source changes, and a pull request that edits scss/ without running the css step ships a repository that disagrees with itself.

Two smaller signals in the same file. The sideEffects array marks every .css and .scss file as side-effectful, which tells a bundler not to drop them when nothing appears to import them. And the package exposes a CommonJS entry at dist/cjs/index.js, an ES module entry at dist/esm/index.js and type declarations at dist/esm/index.d.ts, which is what the base, cjs and esm TypeScript configurations exist to produce.

A typed JavaScript entry point the README never explains

Here is the documentation gap worth naming plainly. The package publishes a CommonJS main, an ES module module field and TypeScript declarations, and the Usage section documents none of them.

Basic Use is a class name on an i or span element. SVG Sprites is a use element with a fragment identifier. SVG Symbols is a symbol definition with a title and a path. Every documented path to an icon goes through markup, and there is no import statement, no exported symbol name and no list of what the JavaScript entry point actually contains. A TypeScript developer who writes import from @coreui/icons and expects typed icon data will get declarations and no documentation of the surface they describe.

The README's answer to the framework question is three separate repositories: CoreUI Icons for Angular, CoreUI Icons for React and CoreUI Icons for Vue, each linked rather than described. So the components you are most likely to want are not in this package, and choosing a wrapper means adopting a second dependency whose own compatibility with your framework version is not stated here. The wrappers are the right place to look for a typed API, and the README's job of pointing at them is a starting point rather than a specification.

The free set is also positioned against a paid one. The README notes that if the free set is insufficient you can buy CoreUI Icons Pro with more than 2000 icons and more styles, naming Solid, Duo-Tone and Linear. The linear style is the cil- set you already have, which means the paid tier is a breadth and style-count difference rather than a different kind of asset, and the migration path from free to Pro is a class name change within the same three-prefix scheme.

Three wrapper repositories and a three-year release gap

The version history is the part that should shape your pinning strategy.

The three most recent releases are v3.1.0 on 2026-04-16, v3.0.1 on 2023-03-07 and v3.0.0 on 2023-01-26. That is a gap of just over three years between the last 3.0.x and 3.1.0, and package.json still reads version 3.1.0, so the published package matches the newest tag. The last push was on 2026-09-11, about five months after that release, which means the default branch carries work that is not in any tag.

For an icon set this cadence is unremarkable. Icons are not software with a defect list, and a new release only happens when drawings change. The consequence for you is that the marketing number, more than 1500 free icons, describes a set whose contents have been stable across a long period, and you should not expect the count to move on a schedule. Pin the version and treat an upgrade as something you do deliberately after checking the diff.

The other structural fact is that the ecosystem is split by host framework, with coreui-icons-angular, coreui-icons-react and coreui-icons-vue maintained as separate projects. That arrangement is how the icons stay host-agnostic, which is a real benefit: the SVG and font assets do not change when a framework does. The cost is that version compatibility is per repository, and the free icon set's own version number tells you nothing about which wrapper version pairs with it.

The project is credited in package.json to creativeLabs, with Łukasz Holeczek named as author and Jazzy Innovations sp. z o.o. listed as a contributor alongside the CoreUI Team, and the preview and documentation site is coreui.io/icons/.

Editorial conclusion

Adopt CoreUI Icons if you want a large set with the three delivery modes that matter, and if you are willing to keep the attribution that CC BY 4.0 asks for on the icon files. Do not adopt it on the strength of the package.json licence field, which reads MIT and covers only the non-font, non-icon files, and do not treat the brand glyphs as free logos: they are CC0 as copyright but trademarked by their owners and the terms restrict them to representing the company, product or service they refer to. Verify three things. Run your licence scanner against the icons directory rather than the package, because a tool reading a single licence field will get this package wrong. Check the brand and flag bundles are not in your global stylesheet, since all.min.css ships free, brand and flag together. Then confirm the version you pin, given v3.0.1 dates from 2023-03-07 and v3.1.0 from 2026-04-16, a three-year gap in which the icon count and style coverage have almost certainly not moved much. The deciding detail is that this is a design asset with a slow release train, so pin the version and treat a new release as an event rather than a routine.

Frequently asked questions

Official sources

1. coreui/coreui-icons on GitHub
2. Issues
3. Project website
4. README
5. Releases