Codicons: the SVG sources behind the Visual Studio Code icon font

The SVG is the source, the font is the output

Codicons is the icon font for Visual Studio Code, and the pipeline inverts what you might expect. The repository does not primarily contain a font. It contains SVGs, and the font is generated from them.

The tool takes the Visual Studio Code icons and converts them into an icon font using fantasticon, and the Visual Studio Codicon Lookup at microsoft.github.io/vscode-codicons/dist/codicon.html lets you preview and search for icons.

All icons are stored under `src > icons`. The mappings of the class names and unicode characters are stored in `src/template/mapping.json`, and the default styles under `src/template/styles.hbs`.

That last detail is a nice piece of design. The class name and the codepoint are separated from the artwork, so the SVG folder can be replaced wholesale without losing the mapping, and the mapping file is the single place where a glyph's name is tied to its character. The Handlebars template means the CSS class definitions are generated rather than hand written, which is how a font of this size stays consistent.

The version numbers in the release history reflect that this is generated output on a regular cadence. The recent releases are v0.0.46-45 on 2026-10-14, v0.0.46-44 on 2026-10-07 and v0.0.46-43 on 2026-10-03, so the build suffix after the patch version increments on each release.

The manifest even carries a separate `fontVersion` field at 1.15, which is distinct from the package version, and that is the number that tells you whether the icon set itself has changed rather than just the package.

Using it: CSS classes and an SVG sprite

There are two ways to consume the icons, and the documentation covers both.

The CSS class route is the one VS Code itself uses. When needing to reference an icon in the Visual Studio Code source code via CSS classes, you create a dom element or container that contains `codicon` and the icon name:

<div class='codicon codicon-add'></div>

The recommendation that follows is worth heeding. It is recommended to use a single dom element for each icon and not to add children elements to it.

That is not a style preference, it is a correctness requirement for a font based glyph. An icon font works by painting a character through the font's glyph, and if the element has children, those children are laid out inside the glyph box, and the result is text sitting in the middle of an icon. It renders wrong in a way that is hard to diagnose from the CSS alone.

The SVG sprite route is the other option. When needing to use the `codicon.svg` sprite file, you reference icons with the SVG use element:

<svg>
    <use xlink:href="codicon.svg#add" />
</svg>

The sprite is produced by the `sprite` script, `node ./scripts/svg-sprite.js --outDir dist --outFile codicon.svg`, so it is a build artefact alongside the font rather than something checked in by hand.

For extension authors, the documentation points at a webview extension sample in the vscode-extension-samples repository, and it says the same thing twice, once under install and once under the CSS classes section, which tells you how often people ask.

The package itself is installed with `npm i @vscode/codicons`, and there is a note that `vscode-codicons` has been deprecated in favor of `@vscode/codicons`.

The build, which is a pipeline of nine steps

The build script is where the design of the repository is clearest, because it shows the whole journey from an SVG to a publishable package.

npm run clean && npm run svgo && npm run fonts && npm run export-to-ts && npm run export-to-csv && npm run copy-metadata && npm run embed-metadata && npm run embed-svg-data && npm run sprite

Nine steps, and each one produces something a different consumer needs.

`clean` runs `node ./scripts/reset.js`, which empties the output. `svgo` optimises the source SVGs in place with `svgo -f ./src/icons/ --config svgo.config.js`, which is worth doing before the font is generated because every byte in the SVG ends up in the font. `fonts` runs `node ./scripts/patch-fantasticon.js && fantasticon`, and the patch step is the interesting one, since it means the project carries a patched version of the font generator rather than using it as published.

Then the exports. `export-to-ts` generates a TypeScript library from the mapping file, and `export-to-csv` generates a CSV from the built font itself, which is a useful artefact because it is derived from the output rather than the input, so it reflects what was actually produced. `copy-metadata` copies the metadata file and `embed-metadata` and `embed-svg-data` embed the metadata and the SVG data into the built artefacts. `sprite` produces the SVG sprite.

There is also a `dev` script, `npm run build && npm run replace-in-vscode`, and `replace-in-vscode` is the step that copies the built font and the generated TypeScript library into a sibling checkout of the vscode repository. So the local development loop is: build here, copy the results into the editor's own source tree, and see the change in the running editor. That is a workflow for someone who works on the editor itself.

The version scripts are equally explicit, with `version:bump`, `version:patch`, `version:minor` and `version:major` delegating to `node ./scripts/version-bump.js`, and `version:commit` and `version:tag` adding the git operations, including a `--tag` variant.

Adding an icon means four steps and a second repository

The contribution path for a new glyph is short, and it shows that this repository is one half of a pair.

Export your icons, as SVG, to the `src/icons` folder, and add an entry into `src/template/mapping.json` with a new codepoint key, which gets converted into a unicode key, and then run the build command. The build command will also remove any subfolders in the `icons` folder to keep the folder structure consistent.

That last detail is a nice touch of enforcement. A flat `src/icons` folder is a structural invariant that the build maintains rather than something contributors have to remember, which means a stray subdirectory cannot quietly accumulate.

The second step is the important one and it is in a different repository. Next, update the codicons file on the vscode repository, and the linked path is `src/vs/base/browser/ui/codicons/codicon/codicon.ttf`.

So the flow is: the SVG and the mapping go into this repository, the built font goes into the editor's source tree, and the editor is where the icon actually appears. Which means a pull request to this repository alone does not add an icon to Visual Studio Code, and that is a real constraint on how you contribute. The `replace-in-vscode` script exists precisely because the two repositories have to stay in step.

There is one practical gotcha in the documentation that will save you an afternoon. If your icons look broken after converting into fonts, which happens often when exporting as SVG from Figma, you might need to sanitize them using a tool like svg-reorient.

The cause is that a glyph exported from a design tool can carry a transform that a font compiler handles differently from a renderer, so the outline ends up flipped or offset. A reorientation pass fixes the SVG before the font is built, and the project tells you the problem exists rather than leaving you to wonder why your icon is upside down.

Two licences, and a trademark limit

The legal notices in this repository are more carefully separated than most, and the separation matters for anyone shipping the icons in a product.

There are two licences and two files. Microsoft and any contributors grant a license to the Microsoft documentation and other content in this repository under the Creative Commons Attribution 4.0 International Public License, in the LICENSE file. And they grant a license to any code in the repository under the MIT License, in the LICENSE-CODE file.

So the icons and the documentation are CC-BY-4.0 and the build scripts are MIT. The manifest declares the package itself as the CC-BY-4.0 licence field in the manifest, which matches the content being the substance of the package.

The attribution requirement is worth understanding if you use these icons. CC-BY-4.0 asks you to credit the creator, so a product shipping codicons will need an attribution, and the distinction between the content licence and the code licence matters because a project that only wants to use the tooling can do so under MIT without attribution, while one that ships the glyphs is working under the content licence.

The trademark paragraph is the one people skip and should not. Microsoft, Windows, Microsoft Azure and other Microsoft products and services referenced in the documentation may be either trademarks or registered trademarks of Microsoft in the United States and other countries. The licenses for this project do not grant you rights to use any Microsoft names, logos, or trademarks.

Put plainly, you can use the icon artwork under CC-BY-4.0 and you cannot start calling your product Microsoft Visual Studio Code, and the licence file itself is careful not to grant more than it does.

Contributions to the project go through a Contributor License Agreement, with a CLA bot that decorates the pull request, and the project has adopted the Microsoft Open Source Code of Conduct.

The repository also carries `SECURITY.md`, a `RELEASING.md` and a `CODE_OF_CONDUCT.md`, and the build is protected by a CodeQL analysis workflow alongside the build workflow.

Editorial conclusion

Codicons fits anyone building a VS Code extension webview who wants the interface to look native, because the glyph set is the one the editor itself renders, which removes the mismatch between your panel and the surrounding chrome. Skip it if you need an icon set that is yours to rebrand, since the licence covers the documentation and content under CC-BY-4.0 and the code under MIT while the trademark notice says the licences grant no rights to Microsoft names, logos or trademarks. Before you depend on a specific glyph, check the codicon lookup page for the exact name and codepoint, because the font is regenerated and glyph names are the only stable reference. The last push was on 2026-10-14 with version 0.0.46-45.

Frequently asked questions

Official sources

1. License: CC-BY-4.0
2. microsoft/vscode-codicons on GitHub
3. Project website
4. README
5. Releases