Material Design Icons (SVG)

@material-design-icons/svg packages Google’s official Material Design Icons as ready-to-use SVG files, published from the marella/material-design-icons monorepo alongside a sibling icon-font package. Every icon ships in five visual styles — filled, outlined, round, sharp, and two-tone — each holding the same catalog of over 2,100 icon names, so switching styles is just a change of import path.

A scheduled GitHub Actions workflow re-downloads the source icons from Google’s font CDN daily, runs them through an SVGO optimization pass, and republishes the package automatically, so consumers never have to manually track Google’s icon releases. Because each icon is a plain SVG file, the package pairs naturally with tools like @svgr/webpack to import icons as React or Vue components, or with any build pipeline that can inline raw SVG.

What You Get

• SVGs for over 2,100 Material Design icons in five styles — filled, outlined, round, sharp, and two-tone
• Consistent per-icon file paths (@material-design-icons/svg/{style}/{icon}.svg) that make swapping styles a one-line change
• Icons pre-optimized with SVGO via a project-specific svgo.config.js, stripping raster images, scripts, and inline styles
• Automatic daily updates via a scheduled GitHub Actions workflow, so new or revised Google icons appear without a manual release
• Apache-2.0 licensed source icons, safe to redistribute inside commercial products

Common Use Cases

• Importing individual icons as React or Vue components via @svgr/webpack instead of bundling an entire icon font
• Building a custom icon component library on top of a consistent, first-party Material icon set
• Swapping icon visual style (e.g., outlined to filled) app-wide by changing a single style-directory segment in imports
• Serving Material Design icons in projects that want tree-shakeable, per-icon SVGs instead of a webfont

Under The Hood

Architecture The svg package itself contains no runtime code — it is a pure data package, a set of directories of pre-generated SVG files organized by style. The actual logic lives in the sibling scripts workspace (svg.js, metadata.js, utils.js), which downloads each icon’s SVG from Google’s font CDN, validates that every downloaded file is well-formed SVG, and hands the result to an SVGO optimization pass at publish time; the update.yml GitHub Actions workflow orchestrates the full pipeline end-to-end (download, optimize, version bump, publish) with no server or application layer involved.

Tech Stack The build tooling is plain Node.js ESM ("type": "module"), using commander for CLI parsing, got for HTTP downloads, and is-svg for validation in the scripts workspace; the svg package’s own build step is a single devDependency, svgo 2.8.0, invoked as svgo --config svgo.config.js --quiet --recursive .. Publishing is coordinated through npm workspaces (font, scripts, svg) at the repo root, with GitHub Actions workflows (update.yml, release.yml, publish.yml) handling the download-to-npm-publish pipeline; there is no runtime framework, database, or server, since this is a pure asset-distribution package.

Code Quality No test files exist anywhere in the repository — correctness is enforced indirectly through sanity checks in scripts/svg.js (checkSvgs confirms every downloaded file parses as valid SVG, checkDownloads asserts nothing is missing) rather than through a unit test suite. The scripts codebase is plain ESM without TypeScript or a linter configuration, though function names and module boundaries are consistent and each function stays small and single-purpose; there is no lint or type-check CI step, only the scheduled update and publish workflows.

API Design The public surface is a file-path convention — @material-design-icons/svg/{style}/{icon}.svg — rather than a JavaScript API, which keeps the learning curve minimal: there is nothing to configure beyond picking a style directory and importing the file, and it composes naturally with @svgr/webpack or any raw-SVG loader without a wrapper library to learn. Documentation is limited to a single README, which is adequate given the design’s simplicity, though the tradeoff is that framework-specific ergonomics (first-party React/Vue components) are left entirely to third-party loaders rather than shipped directly.