SuperTinyIcons: 479 SVG Logos That Stay Under 1KB Each

What SuperTinyIcons solves, and for whom

Most icon sets are built for designers, not for page weight. A single detailed brand logo can run to several kilobytes of path data, and if you are placing twenty of them on a page, that is a real cost. SuperTinyIcons takes the opposite approach: each logo is redrawn as a compact SVG, and the README states there are currently 479 icons with an average size under 534 bytes. The README's own comparison table puts a 527 byte GitHub SVG next to a 3,328 byte PNG of the same mark, and a 235 byte Flickr SVG next to a 1,615 byte PNG.

The audience is narrow and clear. It is for developers who need a recognisable logo next to a link, a footer, a share button or a status badge, and who care about the number of bytes crossing the wire. It is not for anyone who needs the official, multi-colour, pixel-accurate artwork a brand team would hand over. Every icon here is a compromise between recognisability and size, and the README makes no claim otherwise.

How the icons are built: 512x512 viewbox, aggressive minification

The README states the logos have a 512x512 viewbox and will fit in a circle with radius 256. That is the single most useful technical fact about the set: every icon shares the same coordinate space, so you can swap one for another in a layout without recalculating anything. Scaling is handled by the SVG itself, so the same file works at 16 pixels in a toolbar and at 256 pixels in a hero section.

Under 1KB per file means the path data has been reduced to the minimum that still reads as the brand. Curves become fewer, negative space is simplified, and fine detail is dropped. That is why the set can hit an average under 534 bytes while a conventional logo export cannot. The trade-off is fidelity, and it is deliberate: a 188 byte Bandcamp icon or a 220 byte Adobe icon is not the artwork you would find in a press kit.

The repository is not only a folder of SVGs. The top level contains check.py, a src/ directory, a test/ directory, pyproject.toml and package.json, so there is tooling around the image set: a checker, a test suite, and a Python package named sti with console scripts. The README does not document what each script does, so treat the tooling as internal to the project rather than a documented public API.

Installing SuperTinyIcons and using your first icon

The package.json declares the npm package name super-tiny-icons and lists only images/svg/ in its files array, so an npm install gives you the SVG directory and nothing else. The package also declares a postinstall script that runs opencollective-postinstall, which prints a donation message; the trailing `|| true` means a failure there will not break your install.

Install it with npm:

npm install super-tiny-icons

After that, the SVGs are available under node_modules/super-tiny-icons/images/svg/. The README's own image URLs follow the pattern images/svg/<name>.svg, for example images/svg/github.svg, so the file names on disk match the names used in the README table. Copy the one you need into your own assets folder, or reference it directly.

To inline an icon in HTML, open the file and paste its contents into your markup. An inline SVG inherits the text colour through fill="currentColor" only if the file uses it; the README does not state which icons do. The README does not give a command for inspecting the file, so open it in an editor and check the fill attribute before you commit it. If the fill is hard-coded, you can still override it in CSS by targeting the svg element, but you should verify the result in a browser rather than assume it. The README gives no styling guidance beyond the size and viewbox facts.

Where the set breaks down

The first limitation is colour. A logo compressed to a few hundred bytes usually has one fill, and the README does not describe per-icon colour variants or a theming mechanism. If your design calls for the official two-tone or gradient version of a mark, this set will not give it to you, and recolouring a minified path can flatten shapes that were separated only by colour.

The second is detail. Icons that depend on fine linework, small text or intricate negative space cannot survive under 1KB. A 965 byte AngelList icon is near the ceiling of the set, and even at that size the shape has been simplified. Do not expect a favicon that holds up when someone zooms in.

The third is that this is a static asset collection, not a runtime library. There is no sprite sheet, no icon font and no documented API for querying the set. You pick files and ship them. If your build needs programmatic access to a catalogue with metadata, the README does not describe one, and the Python package in the repository is not documented as a public interface.

Finally, brand logos are trademarks. The repository ships a LICENSE file, but the top-level licence field is reported as NOASSERTION while package.json declares MIT. Those two signals disagree, and the README does not resolve the question of what rights you have to the underlying marks.

How it differs from other icon approaches

The related searches around this project point at several other icon sources, and the difference is worth being precise about. Sets such as Gilbarbara logos or Svgl are also logo collections, but they generally ship higher-fidelity artwork at larger file sizes. If you need a logo that matches a brand's official rendering, those are the more appropriate starting point, and you pay for it in bytes.

General-purpose icon libraries such as EvilIcons or Bytesize icons take a different route again: they provide a consistent visual language for interface symbols (arrows, search, close) rather than third-party brand marks. SuperTinyIcons is not trying to be a UI icon set. It is a set of other companies' logos, redrawn small.

The practical difference comes down to a single number. If your budget per icon is roughly half a kilobyte and the mark only needs to be recognisable, SuperTinyIcons is the shortest path. If your budget is a few kilobytes and the mark needs to be correct, use a higher-fidelity source and accept the weight.

Maintenance, upgrades and licence questions

The last push to the repository was on 2026-05-18, and the most recent release listed is v0.5.1, tagged as an archival release on 2025-08-25. The release before that, v0.5.0, dates from 2022-12-31. The gap between those two releases is worth noting: this is a project that moves in bursts rather than on a schedule, and the package.json version (0.6.0) is ahead of the latest tagged release (v0.5.1), which means the published npm version and the release tags do not line up.

Upgrade cost is low in the sense that the artefacts are static files. Swapping a new version in cannot break your build the way a changed API can. The cost is visual: an icon may be redrawn between versions, and if you have inlined the SVG into your markup rather than referencing it, you will not pick up the change until you manually re-copy the file. There is no documented changelog in the README.

On licensing, the repository's top-level licence is reported as NOASSERTION while package.json declares MIT. The README does not discuss trademark rights, and neither file, as far as the repository shows, addresses whether you may use these marks in a commercial product. That is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt SuperTinyIcons if you need small, single-colour brand marks for a web page, a README or an app toolbar, and you accept the trade-offs of aggressive minification. Do not adopt it if you need official multi-colour artwork, detailed logos, or symbols that survive at very large sizes. Before shipping, verify the byte size and visual fidelity of the exact icons you plan to use, and check the licence file in the repository rather than trusting the package metadata alone.

Frequently asked questions

Official sources

1. edent/SuperTinyIcons on GitHub
2. Issues
3. Project website
4. README
5. Releases