# Health Icons: public domain icons for health projects > Health Icons is a volunteer-made set of health icons released into the public domain under CC0, so they can be used in commercial work without credit and edited freely. The repository is the website that serves them, a Next.js application whose build pulls icon metadata and open graph images straight out of a shared Figma file. **resolvetosavelives/healthicons** — A collection of open source icons for public health projects. - Repository: https://github.com/resolvetosavelives/healthicons - Website: https://healthicons.org - Stars: 876 · Forks: 72 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/resolvetosavelives-healthicons ## Two licences, and the one that matters to you Health Icons is a collection of open source icons for public health projects, and the licensing is unusually generous. The README says the icons are available in the public domain under CC0 for use in any type of project, and the headline line says you do not need to give credit and you can edit the icons however you want. The repository itself is a separate thing with a separate licence, MIT, which covers the website code, the scripts and the build configuration. So the two artefacts have different terms and both are permissive: the artwork carries no obligations at all, and the code carries the standard MIT obligations. Neither requires an attribution line in a product, which is the practical difference from most free icon sets. The project describes itself as a volunteer effort to create a global good for health projects all over the world, and the framing explains some of the design decisions. Health pictograms are used in clinics, on forms, in apps for people with low literacy, and in campaigns, and the cost of a bespoke illustration set is the reason such projects often fall back on clip art. Public domain removes both the cost and the negotiation. The repository is TypeScript, the default branch is main, the homepage is healthicons.org, the last push was on 2026-10-19, and the repository publishes no GitHub releases. The package manifest is at version 2.0.0, which is the version of the npm package rather than a tagged release of the code. ## Outline and filled, SVG and PNG, in three sizes The format coverage is the practical part of the offer, and the README lists it precisely. All icons are produced in outline and filled styles. Each icon is available in SVG and in PNG at 48px and 96px, and many icons are also available in a smaller 24px format. The two styles matter more than they first appear, because a health pictogram set usually has to work in two different visual systems: an outline style that sits inside a thin-line interface and a filled style for solid backgrounds. Having both from the same drawing means the pair looks like a set rather than two imported assets. The size coverage is the second half. The 24px format is described as available for many icons rather than all of them, which is the honest phrasing, since a pictogram with a syringe and a drop of blood does not simplify to 24 pixels the way a padlock does. If your interface is dense, that is the constraint to check first, icon by icon, rather than assuming uniform coverage. There are three ways to get the files. Individually from the website, together as a ZIP file at healthicons.org/icons.zip, or through the npm package, installed with npm i healthicons or yarn add healthicons. The npm route is the one that fits a design system, since the package can be a dependency rather than a folder of downloads that nobody updates. ## The repository is the website, and the pipeline is in package.json The top-level listing makes clear that this is a web application: src/, public/, styles/, a next-env.d.ts, a tsconfig.json, a jest.config.js, a testSetupFile.ts, an .eslintrc.js, a .prettierrc.js, a .stylelintrc, a .nvmrc and a yarn.lock, alongside the .env.example and the public/ directory that holds the exported artwork. The scripts in package.json describe the whole flow, and they are worth reading because they are the project's real architecture. ```json "update-icons": "yarn import-meta-data && yarn generate-icon-og-images && yarn generate-site-map && yarn remove-svg-backgrounds", "import-meta-data": "NODE_ENV=local ts-node-dev ./src/scripts/importMetaData.ts", "generate-site-map": "NODE_ENV=local ts-node-dev ./src/scripts/generateSiteMap.ts", "remove-svg-backgrounds": "./src/scripts/removeSvgBackgrounds.sh", ``` The site itself is a standard Next.js application, with dev running next dev, build running next build with a prebuild step that generates the sitemap, export running next export and start running next start. The one non-standard step is remove-svg-backgrounds, a shell script rather than a TypeScript one, which strips the background from exported SVGs so they inherit the colour of wherever they are placed. Testing is Jest, with test running jest --watch for local work and test:ci running the same suite in CI mode with a JUnit reporter for the workflow. Linting is split between ESLint over the component, library and page directories and Stylelint over the CSS in src and styles. The dependency list shows a Next 13 era toolchain, with eslint-config-next at 13, React type definitions at 17 and Jest types at 26, which is a couple of generations behind current releases but stable and self-consistent. ## Figma is the source, and update-icons is the bridge The icons are drawn in Figma, and the repository is the pipeline that turns a Figma export into a website update. That split explains the workflow, and the README is explicit about it. To pull the latest icon information from Figma, you copy .env.example to .env.local, generate a personal access token in your figma.com account settings, and put it in the environment file. The example file is two lines: ```bash FIGMA_PERSONAL_ACCESS_TOKEN= FIGMA_FILENAME="mbsBVYXECIOl5E0kkGAiC2" ``` The second line is the identifier of the shared Figma file, hardcoded in the example, and the first is the credential you supply. After setting FIGMA_PERSONAL_ACCESS_TOKEN with your token, you run yarn update-icons, which chains the import of the metadata, the generation of the open graph images, the generation of the sitemap and the removal of the SVG backgrounds. If you are committing to a branch, you have to remember to add the newly generated files in the /public/ directory, which is the kind of step that is easy to miss and produces an incomplete site. Publishing new icons is a longer sequence, and it is worth following exactly. You run the site locally, delete all of the icons from your local /public/icons/png/ and /public/icons/svg/ directories so that removed icons disappear, go to the Export page in Figma, make sure all new icons are tagged, export all as 1x PNG and 2x PNG, export all as SVG, run yarn update-icons in your terminal, test the site at localhost:3000, commit to a branch, raise a pull request, request a review from another volunteer over Slack, wait for the review, and merge. The delete-then-export ordering is the detail that matters: the site is a mirror of the Figma file, not a collection of files that get added to. ## Tagging is the contract that makes icons findable The metadata convention is unusually well specified, and it is the part of the project that determines whether the set is usable at scale. Each icon carries a title and tags, and both are added in the Description field in Figma. The format is {title} [{tag1}, {tag2}, {tag3]..., dhis2:{tag}], and the README gives two worked examples: ```bash Donkey [Animal, Ass, Farm, Mule, dhis2:donkey] Blood Type RH+ [Blood, RH Positive, dhis2:blood_rh_p] ``` Four rules follow from that. The Description only has to go on the filled version of the icon, so a designer is not writing metadata twice. Titles should be in Title Case with each word capitalised, and tags should be Title Case as well. Tags are essentially synonyms or important related words that help someone find the icon, and they can also be alternative uses, the way a donkey can represent farm, so a person searching for blood or positive sees every icon tagged with those words. And the dhis2 prefix is a namespaced tag, which suggests interoperability with a health information system rather than a purely descriptive keyword. The blood example also shows the naming convention for the icon file itself, blood_rh_p, and the donkey example shows the ordinary descriptive name. That combination, a readable filename plus a search-oriented tag list plus a namespaced code, is what lets the same set serve a designer browsing the site, a developer searching for an icon, and a system that wants a stable identifier. ## Contributing means a fork, a branch and a review from a volunteer The contribution path for the code is spelled out as eleven steps, and it is the intended way to contribute to the code base. You fork the main repository, clone your fork with gh repo clone, add a remote referencing the main repo with git remote add upstream, fetch that remote, create a branch based on the main branch with git checkout -b my-branch-name upstream/main, install dependencies with yarn install, run the project with yarn dev, make your changes and a bunch of commits, push to your branch, and open a pull request from your branch to upstream/main. An admin of the project then reviews it and offers feedback or merges it. Designers follow a different route. You join the open Slack channel by emailing contact@healthicons.org, browse the Figma file and contribute icons in the New icons section, and you are asked to read the code of conduct and the styleguide in the Figma carefully before contributing. The code of conduct itself is a full document with the usual list of expected behaviours, from welcoming and inclusive language to accepting constructive criticism, and the unacceptable list from trolling and personal attacks to publishing private information without permission. If you need an icon that does not exist, there is a third route that is deliberately lightweight. You submit a request with an issue on GitHub, using the icon-request template, the title format "Icon Request: [name of icon]", and the icon request label, and the project says it will do its best to respond. The title format is enforced by the issue template, which suggests the request queue is sorted by that string rather than read by hand. The request-and-review loop is the same loop that runs the whole project: someone identifies a gap, a volunteer fills it, another volunteer reviews it, and it lands in the site. ## What the set does not solve Three limitations are visible in the documentation rather than hidden, and they shape how you would use the set. The first is that the artwork is a Figma file with a manual export step. A designer tags and exports, a script imports, and a volunteer reviews the diff. There is no live sync, so a change in Figma is not in the website until somebody runs the pipeline. For a public health project that updates a handful of pictograms a year, that is a fine trade. For a product that needs an icon added weekly, it is a constraint on your own process. The second is the 24px coverage, which the README describes as available for many icons rather than all of them, and the two-style requirement, which means a design system has to decide whether it uses the outline set, the filled set or both. The third is that gaps are handled by request, which means they are handled by another person's time. The README's promise is that it will do its best to respond, and for a volunteer project that is the honest formulation. The practical advice is to file the request with the exact title format and let the maintainer decide, rather than drawing a near-miss icon yourself, because a set with a hundred consistent pictograms is more useful than a set with a hundred and one. On the other side, the things that usually go wrong with free icon sets do not apply here. There is no attribution requirement, the licence is public domain, the artwork can be edited, the files are in vector format, and the project has been pushed to as recently as 2026-10-19. ## Conclusion Use Health Icons when your project needs pictograms for health services and cannot afford per-project design time, because the set is public domain, editable, available as SVG and PNG and installable from npm, and it covers domains that most icon libraries ignore. Do not expect a managed icon service, since there are no releases, the icons are authored in Figma by volunteers, and a new pictogram still goes through a request issue and a review. Before you publish, check the outline and filled variants against your own guidelines, and if you need something that is not in the set, file the icon request with the exact title format rather than drawing a near-miss yourself, because the set is more useful when the gaps are closed deliberately. ## FAQ ### Do I need to give credit when I use Health Icons? No. The README says the icons are available in the public domain under CC0 for use in any type of project, that you do not need to give credit, and that you can edit the icons however you want. The repository code itself is under the MIT licence. ### How do I install the Health Icons? Individually from the website, together as a ZIP file at healthicons.org/icons.zip, or through the npm package with npm i healthicons or yarn add healthicons. The icons come in outline and filled styles, as SVG and as PNG at 48px and 96px, with many also in a smaller 24px format. ### How do I request a new Health Icon? Open an issue on GitHub using the icon-request template, with the title written as Icon Request: [name of icon]. The README says the project will do its best to respond, and new icons are drawn in the shared Figma file by volunteer designers. ### How do I update the website after new icons are drawn in Figma? Copy .env.example to .env.local, add your FIGMA_PERSONAL_ACCESS_TOKEN, then run yarn update-icons, which imports the metadata, generates the open graph images and the sitemap, and removes the SVG backgrounds. The files generated in the /public/ directory have to be committed with your changes. ## Sources - [Issues](https://github.com/resolvetosavelives/healthicons/issues) - [License: MIT](https://github.com/resolvetosavelives/healthicons/blob/main/LICENSE) - [Project website](https://healthicons.org) - [README](https://github.com/resolvetosavelives/healthicons/blob/main/README.md) - [resolvetosavelives/healthicons on GitHub](https://github.com/resolvetosavelives/healthicons) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/resolvetosavelives-healthicons