Comparison
GlyphPact and IcoMoon solve overlapping problems differently
IcoMoon is a mature browser application for building icon fonts and web assets. GlyphPact is a command-line compiler for keeping a generated icon font under version control. They overlap, but neither replaces the other outright, and this page tries to say exactly where the line is.
Browser sessionselection.jsonExport pack
Human-replayed workflow
SVG directoryCommitted lockCI check
Build-verifiable workflow
Short answer
Which one you want
Choose IcoMoon when
- You need a web icon font with a stylesheet, ready to use.
- You want to browse, search, and visually edit glyphs, or pull from large bundled icon libraries.
- You want React, Vue, or Elm components, or SVG sprites and PNGs.
- Icon changes are occasional and done by a person, not a build.
Choose GlyphPact when
- The icon pipeline should live in the repository and run in CI.
- You need a build to fail when generated output stops matching its sources.
- You are shipping Flutter and want const
IconData. - You want unsupported SVG features reported as typed diagnostics rather than approximated.
First, a correction worth making
IcoMoon is frequently described as a service you upload artwork to. According to IcoMoon's own documentation, that is not accurate, and it matters enough to state plainly before comparing anything else.
IcoMoon's FAQ states that almost everything you do inside the IcoMoon app happens locally
, that when you import SVG files or generate a font everything happens in your browser
, and that your SVGswon't get 'uploaded' to our servers; unless you choose to use our paid plans, which enable saving of projects in your account
. It also documents using the app offline after preloading the generate pages.
So "GlyphPact does not upload your artwork" is a true statement about GlyphPact and a poor argument against IcoMoon. The real difference is not where the bytes go. It is whether the pipeline is a document a person operates or a command a build runs.
Codepoint stability: both have an answer
IcoMoon does preserve codepoints, and the mechanism is documented. Download a pack, keep the selection.json it contains, and import that file when you next change the set. IcoMoon states that the codes of previously selected glyphs will not change when you do.
The condition is the interesting part. IcoMoon also documents thatnewly imported SVGs do not have any codes assigned to them
, and that re-importing all your SVGs and reselecting them each time would most likely result in different codes
. There is also a filename convention, home-U0xE999, for pinning a specific code on import.
Stability therefore rests on a person retaining a file and performing an import correctly, every time, forever, including the time a new teammate does it. That is a real mechanism with a real failure mode, and the failure mode is silent.
GlyphPact moves the same decision into the repository. The registry is a committed file that the compiler reads automatically, so nobody has to remember anything, and a reviewer can see codepoint changes in a diff. More importantly, a build can verify it:
glyphpact --config icon_font.json --check
That difference, not privacy, is the honest reason to prefer a CLI here. A GUI cannot fail your pull request.
How the committed codepoint registry works, with a real diff
Where IcoMoon is simply ahead
IcoMoon's documented export targets include a web font pack, SVG, SVG sprites, Elm, React, Vue, tiles, PNG, favicons, and Photoshop custom shapes. GlyphPact emits an OpenType font, a lock file, a report, an attribution file, and Dart. That is the whole list.
GlyphPact produces no WOFF2 and no CSS, and it has no browser integration. Getting its font onto a web page means converting the.otf with a separate tool and writing the@font-face rule and class names yourself, reading codepoints out of the lock file as you go. If that is the job in front of you, IcoMoon does it now and GlyphPact does not do it at all.
IcoMoon also has something GlyphPact deliberately lacks: a visual interface. Browsing a set, spotting the wrong glyph, nudging a baseline, picking from thousands of existing icons - a text-mode compiler is worse at all of it.
Side by side
The full comparison
| GlyphPactLocal CLI compiler | IcoMoonBrowser app | |
|---|---|---|
| Existing codepoints survive a pack changeIf an assignment moves, shipped application code renders the wrong glyph. | Supported: Committed lock file`iconfont.lock.json` is generated into the output tree and read on every later build. Removed icons leave a tombstone in `retired` instead of freeing the codepoint. | Conditional: If you re-import selection.jsonThe FAQ states the codes of previously selected glyphs will not change when the previous `selection.json` is imported, and that "newly imported SVGs do not have any codes assigned to them", so re-importing and reselecting everything "would most likely result in different codes". Stability depends on keeping that file and importing it every time. |
| CI can prove committed output is currentGenerated artifacts drift from sources silently unless something fails the build. | Supported: `--check` exits 3 when staleRebuilds a candidate artifact set and compares it without rewriting the owned output tree. Verified: exit 0 on current output, exit 3 after a source edit. | Not supported: No CLI to run in CIThe documentation describes a browser application, with no command-line interface. |
| Runs entirely on your machineUnreleased or licensed artwork often cannot leave the building. | Supported: Local CLI, no network stepA Python command-line compiler. No website step, no project service, no server that receives artwork. | Supported: In-browser, not uploadedThe FAQ states that "when you import SVG files or when you generate a font, everything happens in your browser", and that SVGs are not uploaded unless you opt into paid project storage. It also documents working offline after preloading the generate pages. |
| Byte-identical rebuildsNon-reproducible artifacts turn every rebuild into an unreviewable diff. | Supported: Same bytes across worker countsSame inputs, config, lock, and compiler version produce byte-identical artifacts. Verified: identical SHA-256 across default, 1, and 4 worker processes. | Not documented: Not documented |
| Explicit policy for SVG a font cannot holdAn icon font stores monochrome coverage. Something has to decide what happens to a blur or a half-transparent fill. | Supported: Two policy axes, both strict by default`lossy` and `unrepresentable` each default to `error`. Approximations and omissions require explicit opt-in and are reported as typed, coded issues. | Not documented: No published policy |
| Generates a Flutter IconData APIHand-written IconData constants are the place codepoint drift actually bites. | Supported: Const class, tree-shakeableEmits a `@staticIconProvider` class of `const IconData` values, with `fontPackage` handling and optional layered-icon widgets. | Not supported: No Dart outputDocumented export targets are Font, SVG, SVG sprite, Elm, React, Vue, Tiles, PNG, Favicon, and CSH. |
| Web assets: WOFF2 and CSSThe honest place GlyphPact is behind. If you need a web icon font today, these tools already do it. | Not supported: OpenType/CFF onlyEmits a `.otf` font and the lock registry. No WOFF, no WOFF2, no generated CSS. Web use means converting the font and writing the CSS yourself. | Supported: Fonts plus CSSDocumented export targets include a web font pack and further asset types. |
| Generates an attribution recordThird-party icon licences usually require attribution, and audits ask for it. | Supported: `ATTRIBUTION.md` per buildCarries declared author, licence, and source URL per glyph, and counts emitted icons with no declared provenance. It does not verify ownership. | Not documented: Not documented |
| Required runtimeA toolchain you do not already run is a toolchain you have to maintain. | Supported: Python 3.10+Dart 3+ only to consume the generated provider. | Supported: A browser |
| Coding-agent integrationIcon work is increasingly delegated, and an agent needs typed results rather than screenshots. | Supported: Local stdio MCP serverClaude Code and Codex can install the full plugin. Other stdio MCP clients can configure the published server directly. It exposes four tools plus the config, report, and inner CLI-result schemas. | Not supported: Not offered |
They are not mutually exclusive
A reasonable arrangement uses both: design and curate in IcoMoon, export the SVG sources, and commit those sources as the input GlyphPact compiles. The visual work happens where visual work is good, and the build-time guarantees happen where a build can enforce them.
GlyphPact only ever reads your SVG directory, so it does not care what produced the files.
Try it
Point it at a directory you already have
uv tool install glyphpactInstalls the latest stable release from PyPI, currently v1.0.1. Already installed? Run uv tool upgrade glyphpact. Release notes.
IcoMoon behaviour verified on 2026-07-25against icomoon.io/docs andicomoon.io/old-faq. Quoted text is IcoMoon's own. If any of this has changed, it should be corrected.