SVG Gobbler pulls every SVG off a page and turns it into a React component

The problem is that the SVG is in the page, not in your design files

SVG Gobbler is an open-source browser extension that finds, optimises and exports SVG content from any webpage, and the description in the repository header covers finding, editing, exporting, optimising and managing SVG content.

The use case is narrow and specific. When you are building an interface and need an icon, the options are to draw it, to copy it from a design tool, or to take it from a site you like. The third is the slow one by hand, because finding the SVG in the page means opening the developer tools, hunting through the DOM, and copying the markup.

The extension automates that. The find features are listed as discovering SVGs on any webpage across various mime types, handling CORS restricted SVGs with ease, and finding and rebuilding individual sprite SVG instances. That last one is worth pausing on. Icons on a modern site are often not separate SVGs at all, they are fragments of one large sprite sheet, and an extension that can reconstruct an individual icon out of a sprite is doing something a copy-paste approach cannot.

The CORS bullet is a hint about how the extension works. A browser extension running on a page cannot fetch an arbitrary cross-origin resource without the server permitting it, so the extension has to have some mechanism for getting at content the page itself could not fetch. That is a solvable problem for an extension with host permissions, and the bullet tells you the author thought about it.

The privacy statement is unusually direct for an extension. The extension is open source and doesn't collect any user information, it's completely free and made available because the author enjoys creating useful tools for the web community. The project started over seven years ago as a project to improve upon the SVG Crowbar tool, which is no longer maintained by the New York Times, and is now in its fifth major version.

Export targets are the part that decides whether you need it

The export feature list covers five distinct output shapes, and each one corresponds to a different thing you might want to do with an icon.

Create SVG sprites from a collection of icons, so a set of icons becomes one file with symbols. Export in multiple formats, namely SVG, PNG, WEBP, JPEG and more, for when the target is not a vector at all. Transform SVGs into minified Data URIs, which is how you inline an icon into CSS or a component without an extra request. Convert SVGs to React components using SVGR, which turns the markup into a component that accepts props like fill and className. And optimise and minify SVGs with SVGO.

That last pairing is the reason SVGO appears in the dependency list at version 3.3.2. SVGO is the standard optimiser for SVG, and running an SVG through it typically removes editor metadata, collapses paths, drops redundant attributes and reduces coordinates. The gain is real, and so is the risk: an optimiser that rewrites path data can change rendering in edge cases, so the extension showing you the result before you export is the important part.

The data URI route uses the mini-svg-data-uri package, which is the library for producing the shortest possible data URI form of an SVG. That is a smaller detail than it sounds, because the naive encoding of an SVG as a data URI is much longer than the optimised form, and the difference shows up quickly in a stylesheet with a hundred icons.

The React component route is the one that makes this more than a downloader. SVGR at version 8.1.0 in devDependencies, so the conversion is not a runtime feature of the extension but a build-time step it drives.

Organising before you export is the part most tools skip

The organise features are listed as grouping and categorising SVGs by domain or custom collection name, moving, copying, duplicating and optimising icons before sharing, and saving and storing uploaded SVGs for optimisation.

Grouping by domain is the specific idea, and it is a good one. When you have extracted sixty icons from one site, they are all one visual language and they belong together, and the next time you work on that site you want them in one place. Naming a collection yourself covers the case where the icons come from several sites but serve one project.

The uploaded SVGs point is a slightly different feature. Saving and storing uploaded SVGs for optimisation means you can drop in a file you have on disk, or paste an SVG you found elsewhere, and run it through the same optimisation and export path as the ones you scraped. In practice this makes the extension a small asset pipeline as well as a scraper.

The move, copy and duplicate operations sound trivial until you have a hundred icons, where they become the difference between a usable collection and a flat dump. The interface supports that with DND-Kit, listed in the stack as the drag and drop toolkit, along with React Router for routing and Radix UI for unstyled accessible components, with the toast and tooltip packages specifically present in the dependencies.

The stack also includes CodeMirror in three language variants, javascript, json and xml, which is what the editor uses. @uiw/react-codemirror is the React wrapper, and @uiw/react-json-view is a JSON viewer, which suggests the extension has a view for structured data as well as a text editor for the raw markup.

The build pipeline is Vite and CRXJS, with a small local server

The development setup in the README is a standard modern browser extension build.

The prerequisites are Node.js and pnpm, and the project uses pnpm with a pnpm-lock.yaml at the top level. The clone and install steps are:

git clone https://github.com/yourusername/svg-gobbler.git
cd svg-gobbler
pnpm i

After that the development build is started with pnpm start. The scripts in package.json show the shape: start runs vite build and then vite, build runs tsc and then vite build, dev is vite alone, dev-ff changes into dist and runs web-ext run, clean removes dist, release runs pnpm build and then a ts-node script that zips the release, and release-ff builds the Firefox add-on with web-ext build writing to a releases directory.

The split between start and dev is the interesting one. start builds the assets to the dist folder and watches for changes, and dev is the plain vite dev server for subsequent builds, which is faster because it skips the rebuild step.

CRXJS is the build automation, from the chrome-extension-tools project, and it is what makes a Vite-based extension build work with the Chrome manifest and the service worker. The manifest itself is generated rather than static, since the top level has manifest.config.ts rather than a manifest.json, which is the CRXJS pattern.

There is a server directory with its own package.json referenced as file:server in the dependencies, and the README says most functionality works without a server, but for local fetch calls you run it separately with pnpm i, pnpm build and pnpm serve. That is the CORS problem again: some fetches need a server side proxy, and the extension degrades gracefully without it.

For Chrome, the README gives the load unpacked route. Navigate to chrome://extensions, enable developer mode, click Load unpacked and select the dist folder.

Where SVG Gobbler is the wrong tool

The first limit is that it does not solve provenance. An SVG extracted from a website is that website's artwork, and the licence on it is whatever the site author put there. The extension will happily export an icon from a commercial site into your product, and the extension's own Apache-2.0 licence says nothing about the icons you take with it. Any team using this on commercial work needs a separate check on where the artwork came from.

The second is that it is a person-driven tool. Every extraction is a click, every export is a click, and there is no command line and no API for extracting hundreds of SVGs from a list of URLs in a pipeline. The scripts in the repository are for building the extension, not for running it. If your need is bulk asset harvesting as part of a build, this is the wrong shape of tool.

The third is what the SVG contains. A sprite instance that has been recoloured, positioned with CSS, or drawn with a style that lives in the page's stylesheet will not necessarily be reconstructible as a standalone file, and an SVG that references an external font or an image will break when inlined. The extension's job is to get the markup, not to guarantee the asset is self-contained, and a large part of the practical work remains checking what you got.

The fourth is the trust question for an extension. An extension with the ability to read and rewrite the SVG content of every page you visit, and to fetch cross-origin resources, is a powerful thing to have installed permanently. The project states it collects no user information and the source is open, which is the right posture, but the extension still needs broad permissions and that is worth keeping in mind when you decide whether to keep it enabled on every site rather than only when you are harvesting icons.

The fifth is version cadence. The releases are v5.29 in June 2025, v5.30 in November 2025 and v5.31 in March 2026, while package.json is at 5.32.0 and the last push was on 2026-09-09. The project is active, but a major version every year or so means the interface and the internals move, and documentation of your own workflow around the extension may age.

Editorial conclusion

SVG Gobbler suits a front-end developer who needs icons extracted from a live site rather than from a design file, especially when the target is React and the SVGs need to end up as components. It is the wrong tool if you have the original vector assets, and the wrong tool if you need the extraction to run unattended in a build pipeline, since it is a browser extension driven by a person. Before adopting it, check whether the SVGs you care about are reachable, because the README calls out CORS restricted SVGs as a specific case, and note that anything you export is licensed by whoever drew the original icon.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rossmoody/svg-gobbler on GitHub