SVGL: a SvelteKit library of SVG logos you can self-host

What SVGL solves for people who need brand logos

Most icon sets are drawn to a common grid with a single stroke weight. Brand marks are not. A React logo, a Figma logo and a PowerToys logo each arrive with their own canvas, their own colour rules and their own idea of what a light and dark variant should look like. SVGL exists to hold those marks in one place and serve them as raw SVG.

The repository describes itself as "A beautiful library with SVG logos" and is built with SvelteKit and Tailwind CSS. The audience is narrow but real: developers placing technology logos on a landing page, designers pulling marks into Figma, and tool authors who want logo search inside an editor. The README lists extensions for React, Vue, Svelte, Figma, VS Code, Raycast, Framer and PowerToys, which tells you the maintainer expects consumption through other surfaces rather than through this repository alone.

If you need a general-purpose UI icon set, this is the wrong catalogue. SVGL is about recognisable company and product marks, and the data file that backs it is a curated list, not a generated scrape.

How the SvelteKit app, the data file and the API fit together

The top-level layout separates three concerns. The src/ directory holds the SvelteKit application and its components, static/ holds assets including the library logos referenced in the README, and api-routes/ is a separate workspace with its own build step. package.json defines build:api as a change into api-routes followed by pnpm build, so the API is compiled independently of the site.

The logo catalogue itself lives in src/data/svgs.ts. That single file is the source of truth: the site reads it to render the browse and search views, and the checks in utils/ operate on it. One script, check:data, validates the data, and another, check:size, enforces a size budget. A third, fix:viewbox, rewrites viewBox attributes, which is the kind of maintenance a hand-curated SVG collection needs because contributors rarely export to the same canvas.

The README points to a public API at svgl.app/docs/api, and the dependency list shows the supporting machinery: fuse.js for fuzzy search, shiki for code rendering, jszip for bundling downloads, and svgo for optimisation. The badge and CLI extensions listed in the README consume that API rather than the repository directly, so the API is the integration point for anything outside the site itself.

Running SVGL locally and adding a logo

The repository uses pnpm, pinned in package.json as [email protected], with a pnpm-workspace.yaml at the root. The scripts block gives the development entry point directly:

pnpm install
pnpm dev

Vite serves the SvelteKit app on its default port, and you should see the same browse interface as the hosted site. The README does not state a port number, so read the URL Vite prints rather than assuming one.

Before opening a pull request with a new logo, run the data and size checks. These are the two gates that catch a malformed entry or an oversized file:

pnpm run check:data
pnpm run check:size

If a logo renders with the wrong crop, the repository ships a script for exactly that case, since SVGs exported from design tools often carry a viewBox that does not match the artwork:

pnpm run fix:viewbox

For a container build, the Dockerfile is a three-stage Node 24 Alpine image. The builder stage runs check:size and then build:prod, and the runner stage exposes port 3000 and starts the server with node build:

FROM node:24-alpine AS base
ENV CI=true
RUN corepack enable
WORKDIR /app

Note that build:prod depends on build:registry, which generates a shadcn registry into static/r. A Docker build therefore produces both the site and the registry output, and the image is larger than the site alone would suggest.

Where SVGL breaks down as a dependency

The root package.json sets "private": true. That is the clearest limitation in the repository: you cannot install this package from npm and import a Logo component. The project is an application, and the npm wrappers the README lists for React, Vue and Svelte are separate community packages maintained by other people. If your team needs a pinned, versioned dependency with a published changelog, SVGL in its repository form does not provide it.

The second constraint is the data model. Because src/data/svgs.ts is a single curated file, every logo is a deliberate inclusion. A brand you need may simply not be there, and adding it means editing that file, running the checks and opening a pull request. The check:size script exists because the maintainers care about the weight of what goes in, so a large or unoptimised export will fail the build rather than quietly ship.

Third, the release cadence is uneven. v4.0.0 landed in December 2023, v4.1.0 in January 2024, and v5.0.0 in September 2025. The last push to the repository was on 2026-09-17, so work continues, but the gap between v4.1.0 and v5.0.0 is more than a year and a half. Anyone who wants predictable upgrade windows should plan around that rhythm rather than assume monthly releases.

SVGL against Simple Icons and gilbarbara/logos

Simple Icons is the closest comparison and the one most developers already know. Its approach is a monochrome icon set delivered as an npm package with per-icon modules, so you import a single path and colour it yourself. SVGL takes the opposite position: logos keep their brand colour and their original artwork, and there is no per-icon import to tree-shake. If you need one flat glyph on a button, Simple Icons is the better fit. If you need the actual multi-colour mark, SVGL is.

The gilbarbara/logos collection is the other obvious alternative, and the difference is in the delivery. That project is a repository of SVG files organised for direct copying, without a SvelteKit application, a search interface or a documented API around them. SVGL wraps its catalogue in a browsable site, a JSON API and a set of editor extensions, which is why the README can list a Raycast plugin and a VS Code plugin as first-class ways to use it. The trade-off is that you take on a web application when a directory of files might have been enough.

A third option is to draw from the brand's own press kit. That gives you the canonical file with the vendor's usage terms attached, which matters for trademark questions that neither SVGL nor Simple Icons addresses.

Licence, maintenance and the cost of upgrades

The repository is MIT licensed, and package.json repeats that as "license": "MIT". MIT covers the code in this repository. It does not grant rights to the logos themselves. Brand marks remain the property of their owners, and the README lists a sponsorship link alongside the extension table, which is consistent with a project that is not monetising the marks. If you are shipping logos in a commercial product, the licence file tells you nothing about trademark permissions, and that question belongs with the brand owner or your legal team rather than with the repository.

Upgrade cost is concentrated in two places. The first is the data file: if you fork and add logos, every upstream change to src/data/svgs.ts is a potential conflict. The second is the toolchain. The project pins [email protected], runs on Node 24 in the Dockerfile, and depends on SvelteKit, Vite, Tailwind, shiki, fuse.js, jszip, svgo and shadcn. A major SvelteKit or Tailwind release ripples through the build, which is part of why the version history shows long gaps between majors rather than steady minor releases. Self-hosting means owning that upgrade path yourself; consuming the hosted site or the API means you do not.

Choosing between the hosted site, the API and a fork

There are three ways to use SVGL and they carry different obligations. The hosted site at svgl.app is the lowest-effort option: browse, copy the SVG, done. The API documented at svgl.app/docs/api suits anything that needs to fetch logos at runtime, and it is what the Raycast, VS Code and badge extensions in the README build on. Forking the repository is the option for teams that need to add private or internal marks, and that path brings the data file, the check scripts and the container build with it.

The middle option is the one most teams underestimate. An API dependency means the availability and the contents of svgl.app affect your application, and the README does not describe rate limits, caching headers or a stability guarantee for the API surface. If your build fetches logos from that endpoint, treat it as an external service with the usual failure modes rather than as a static asset.

The fork is the honest choice when the catalogue is close but not sufficient. The scripts are already there for you: check:data validates your additions, check:size enforces the budget, and fix:viewbox repairs the exports that design tools get wrong.

Editorial conclusion

Adopt SVGL if you need brand-accurate SVG logos for a site, a design file or an editor plugin, and you are comfortable consuming the hosted site or running the SvelteKit app yourself. Do not adopt it expecting an npm icon package with typed components: package.json marks the root package private, and the React, Vue and Svelte wrappers listed in the README are separate community projects with their own maintenance. Before committing, open src/data/svgs.ts and confirm the logos you need are present, then run pnpm run check:size and pnpm run check:data against your own additions so a large or malformed SVG does not reach your build.

Frequently asked questions

Official sources

1. License: MIT
2. pheralb/svgl on GitHub
3. Project website
4. README
5. Releases