# Rune Icons and the icon set that ships as source, not as a package > Rune Icons is an open-source icon library of more than 900 glyphs in five styles, with a browser editor, per-style sprites and npm packages. The interesting part is the licence split: the icons themselves are Apache 2.0, while the site, editor and components carry a Commons Clause that requires attribution and forbids reselling the website code. **Runeicons/runeicons** — Open-source icon library: 900+ icons in five styles (outline, duotone, fill, pixelated, glass), a browser editor, 1,100+ brand logos, and npm packages - Repository: https://github.com/Runeicons/runeicons - Website: https://runeicons.com - Stars: 704 · Forks: 49 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/runeicons-runeicons ## One glyph, five drawings of the same shape Rune Icons is an open-source icon library where every glyph comes in five styles: outline, duotone, fill, pixelated and glass. The count is 900+ icons, and any of them can be copied as SVG or JSX. The five styles are the differentiator, and the reason is that they are not separate icon sets. The same underlying shape is drawn five ways, so a duotone icon and a fill icon of the same symbol share their silhouette. That is what lets a design system move from a light outline treatment to a heavier duotone treatment for emphasis without redrawing anything or ending up with two unrelated-looking symbols. Outline, described as normal, is the base. Duotone adds a second tone. Fill is the solid version. Pixelated and glass are the two that are less conventional, and they are the ones worth judging on whether they fit your product at all. A pixelated style reads as retro or game-like, and glass reads as a translucent overlay effect. Both are defensible choices, and both are wrong for a large share of interfaces. The library is browsable at runeicons.com, with search and filtering by name, category or tag. The audience is front-end developers and designers who want a coherent set rather than a grab bag assembled from several sources, and who want SVG and JSX output rather than a font file. ## The browser editor and what it actually outputs There is a built-in editor, and the feature line is specific: you can reshape any path in it, then copy the result out as SVG or JSX. That is the difference between an icon library and an icon editor. Most libraries give you a fixed path, and if the geometry is not quite what your layout needs, you either scale it and accept the result or open a vector tool and start again. Here the path is editable in the browser, and the output is still SVG or JSX, so the edit is a normal design step rather than a detour into another application. Output format matters more than it sounds. SVG means you can inline the markup, style it with CSS, and animate it, with no font loading and no extra network request. JSX means the icon is a component rather than a string of markup, which means it can take props and participate in your component tree. The site is a Next.js 16 application with React 19 and Tailwind CSS v4, deployed on Vercel, with the pnpm workspace at the root. The editor itself is part of the site code, and that matters for the licensing question covered below. The npm packages live in packages/ and are part of the same pnpm workspace as the site, so the library and the site are developed together rather than the site being a consumer of a published package. ## Sprites and the manifest scripts that generate them The repository has generated artefacts, and there are two scripts that rebuild them, both of which run on Bun rather than Node. The icons:sprites script regenerates the per-style sprites in public/sprites/. A sprite is a single image holding many icons, which lets a page load one file and address icons inside it, usually with a fragment identifier or a viewBox offset. That is the standard technique when you have hundreds of small glyphs and care about request count. The icons:manifest script regenerates lib/icons/manifest.generated.ts from public/. That generated manifest is the machine-readable index of what exists, and it is the file the packages consult to know which icon names and styles are available. It also means the source of truth for the icon set is the SVG files in public/, with the manifest and the sprites derived from them. The two styles live in separate public directories, public/normal, public/duotone, public/fill, public/pixelated and public/glass-icons, with the sprites alongside. The README lists those directories as part of the Apache 2.0 licensed set. There is a third generator, docs:readmes, which builds the per-package README files, and a separate React Native package whose icons are generated with its own script, invoked as icons:rn. The practical point is that this is a build-time pipeline, not a static asset dump. If you fork it, the icons, the manifest, the sprites and the package docs all have to be regenerated after an icon change, and the CI will expect that. ## The scripts, the toolchain and the local workflow Running the site locally needs Node.js 20 or later, pnpm 10 and Bun, and the README notes specifically that the icon scripts and package tests run on Bun. The clone and start sequence is short: ```bash git clone https://github.com/Runeicons/runeicons.git cd runeicons pnpm install pnpm dev ``` The site is then at http://localhost:3000. The script table covers the ordinary Next.js lifecycle plus the icon generators. pnpm dev starts the development server, pnpm build is the production build, pnpm start serves that build, pnpm lint runs ESLint and pnpm format runs Prettier over the codebase. The package tests are run per package or across the workspace. A single package is tested with pnpm --filter runeicons-react test, and every package with pnpm -r test. The pnpm version is pinned at 10.34.5 in the package manager field. The dependency list is a modern Next.js stack, and it is worth noticing what is in it. Radix UI provides the unstyled primitives for the accordion, dialog, dropdown menu, select, slider, slot, switch and tooltip, with class-variance-authority and tailwind-merge handling variant composition. Lucide React is present as an icon dependency alongside the project's own icons, motion and GSAP handle animation, zustand handles state, and marked and shiki render Markdown with syntax highlighting. dompurify is there for sanitising, which matters for a site that renders user-supplied Markdown. The contributing guidelines are pointed at for setup, repository structure and how to add new icons, and the repository includes a code of conduct, a security policy and a vercelignore alongside the config. ## Brand logos are a different legal animal from the icons The /brands page lists more than 1,100 logos of the tools developers and designers use, covering AI tools, languages, frameworks, databases, cloud platforms and design tools. Each logo comes with its license, a link to the brand's official site and a link to the brand's own guidelines, and you can like, copy or download any of them as SVG. The licensing section here is the part to read carefully. The files in public/brand-logos/ belong to their respective owners, each keeps the license listed in constants/brand-logos.ts, and the logos are not part of either of the project's own licenses. There is a NOTICE file in that directory. The README is explicit that these are trademarks of their owners, that they are not covered by the Apache 2.0 licence, that you should follow each brand's own guidelines, and that you should not alter their logos. If you own a logo and want it removed or corrected, the project asks you to open an issue. So the icon set and the logo set have completely different terms, and the difference is not subtle. A logo you ship in a footer is a trademark use governed by the brand's guidelines, not an Apache 2.0 asset you can modify freely. The 1,100 logos are a convenience for finding and previewing the right file, not a blanket licence grant. If your project is a marketing site with a client logo wall, this is a real constraint, and the practical answer is that many brands have their own asset pages, which is what the guidelines link is pointing at. ## Two licences in one repository Rune Icons uses two licences, and the split runs through the repository by directory. The icons are under the Apache License 2.0. That covers the icon SVGs in every style, meaning public/normal, public/duotone, public/fill, public/pixelated and public/glass-icons, the sprites, the lib/icons code, and the packages in packages/. These are free for personal and commercial use, and no attribution is required. That is the cleanest possible position for the part most people will actually use. Everything else is under Apache License 2.0 plus Attribution plus the Commons Clause. That covers the landing page, the UI components, the animations, the editor and the rest of the website code. The three rules are: use it anywhere including commercial and client work, credit it, meaning a project shipping any part of it must credit the Rune Icons Team with a visible link to runeicons.com such as in a footer, an about page, a credits screen or a README, and do not resell it, meaning the landing page designs, components and animations may not be sold, sublicensed or redistributed, whether alone, in a bundle or as a port. That third rule is the one to understand before you copy a component into a paid product. You may use the editor and the components in a client project and credit the team, but you may not package them as something you sell. The copyright line is the Rune Icons Team, 2026, and GitHub shows the repository licence as one it cannot classify, which is what a Commons Clause combination looks like to an automated detector. Read the LICENSE file rather than relying on the badge. ## Maintenance and what the project does not tell you The repository is not archived and the last push was on 2026-10-11, so work is current. The root package.json version is 1.1.0 and the package is marked private, which refers to the workspace root rather than the published icon packages, and there are no GitHub releases. That last point is worth pausing on for an icon library. There is no tagged version of the site or the workspace, so the npm packages in packages/ are versioned independently, and the README does not say how those versions relate to the icon set in public/. If you depend on a published package, pin it and check that the icons you rely on are present in that version rather than assuming the latest package matches the latest commit. Two further gaps are worth naming. The README does not document how the pixelated and glass styles are generated, whether the five styles are hand-drawn or derived from one another, so if you want to add your own icon in a matching style you would be working without instructions. And the brand logo list is described as living in constants/brand-logos.ts with each entry carrying a license and a guidelines link, but the README does not describe a process for adding a logo, only for reporting one that is wrong. The project is at the stage where the components and the site are the same codebase, which is efficient and also means the site's design decisions and the icon set's release cadence are coupled in a way a pure icon package would not be. ## Conclusion Rune Icons is a good fit for a project that needs a consistent icon set across five visual weights without maintaining a single-style library, because the outline, duotone, fill, pixelated and glass variants share geometry rather than being separate drawings. It is a poor fit for a design system that requires the library code itself to be redistributed in a paid product, because the site, editor and UI components carry a Commons Clause that forbids reselling them, and it is a poor fit if you need brand logos you are allowed to modify, since the README says not to alter them. Before adopting, check which of the two licences applies to what you are shipping, decide whether the pixelated and glass styles fit your visual language rather than assuming all five are usable, and read the brand guidelines list in constants/brand-logos.ts before pulling a logo into a product. ## FAQ ### How do I use Rune Icons in a project? Copy any icon as SVG or JSX from the site, or use the npm packages in the packages/ directory. The SVG files live in public/normal, public/duotone, public/fill, public/pixelated and public/glass-icons, with per-style sprites in public/sprites/. ### What licence applies to the Rune Icons icons? The icon SVGs in every style, the lib/icons code and the packages are under Apache License 2.0, free for personal and commercial use with no attribution required. The landing page, UI components, animations and editor are under Apache 2.0 with attribution and the Commons Clause, which requires a visible credit link and forbids reselling them. ### Can I use the brand logos from Rune Icons in my project? The logo files in public/brand-logos/ belong to their respective owners and are not covered by either project licence. The README says to follow each brand's own guidelines and not alter their logos, and each entry in constants/brand-logos.ts lists the license and the brand's official guidelines link. ### How do I run the Rune Icons site locally? You need Node.js 20 or later, pnpm 10 and Bun, since the icon scripts and package tests run on Bun. Clone the repository, run pnpm install and pnpm dev, and the site is at http://localhost:3000. ## Sources - [Issues](https://github.com/Runeicons/runeicons/issues) - [Project website](https://runeicons.com) - [README](https://github.com/Runeicons/runeicons/blob/main/README.md) - [Runeicons/runeicons on GitHub](https://github.com/Runeicons/runeicons) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/runeicons-runeicons