Devicon is an MIT licensed collection of logos for programming languages, frameworks, databases, cloud platforms and developer tooling. It covers a few hundred technologies, and because most of them ship in several variants the file count runs into the thousands.
It exists because general logo sets do not cover this ground well. Simple Icons has consumer brands. Devicon has PostgreSQL, Kubernetes, Rust, Terraform, Redis and the long tail of things a developer actually works with.
The short version
Each technology has up to four base variants: original (official colours), plain (single colour, flat), line (single colour, outline), and their -wordmark versions with the name included. Use original for stack showcases, plain for anything that has to match your design system. Licence is MIT, but the logos are still trademarks.
The variant system explained
Devicon file names follow the pattern technology-variant.svg, for example react-original.svg or python-plain-wordmark.svg. The variants mean specific things:
| Variant | What you get |
|---|---|
original | The logo in its official brand colours, including gradients where the real mark has them |
plain | The same silhouette flattened to a single colour, filled |
line | A single-colour outline version, stroke rather than fill |
*-wordmark | Any of the above with the technology name included in the artwork |
Not every technology has every variant, which is the main source of confusion. A logo that is inherently multi-colour may have no meaningful line version. A logo that is a wordmark to begin with may not have a standalone glyph. Searching visually rather than guessing at filenames avoids the problem entirely.
Which variant to use where
| Context | Variant | Why |
|---|---|---|
| Portfolio tech stack | original | Instant recognition, colour does the identifying |
| Footer or nav | plain | Sits inside your palette without shouting |
| Dark background | plain, set to white | Many original marks have dark elements that vanish |
| Documentation sidebar | plain or line | Matches surrounding UI icon weight |
| Logo used alone, no label | *-wordmark | The name is part of the artwork |
| Small sizes, under 20px | plain | Detailed original marks turn to mud |
The dark background case is worth flagging because it catches people repeatedly. Plenty of official logos contain black or near-black elements that were designed to sit on white. Dropped onto a dark hero section, half the mark disappears. Switch to plain and set it to white or a light tint rather than trying to patch the original.
Building a tech stack section that works
Most tech stack sections are a grid of logos and nothing else, which is a wasted opportunity in two directions.
- Label every logo. Not everyone recognises the Terraform mark. A logo with its name underneath is readable to a wider audience, and the text is content a search engine can actually use. A grid of unlabelled images is content-free.
- Group by role. Languages, frameworks, data, infrastructure, tooling. An ungrouped grid of 24 logos communicates "we use a lot of things". A grouped one communicates how you build.
- Say something about each. One line explaining why you use it turns a logo wall into content someone might read. This is also the difference between a page with substance and a page that looks generated.
- Normalise optical size. Wordmarks are wide, glyphs are square. Set them to equal visual weight, not equal width.
- Cap the list. Twelve well-chosen logos read as expertise. Forty read as a keyword dump, to readers and to search engines.
Devicon in a GitHub README
GitHub sanitises inline SVG in markdown, so you cannot paste an SVG element into a README and expect it to render. You have two workable routes.
Reference the file by URL in an image tag, which keeps the README small and always current:
<img src="https://cdn.jsdelivr.net/gh/devicons/devicon/icons/react/react-original.svg"
width="40" height="40" alt="React">Or commit the SVGs to the repo and reference them relatively. This is slower to set up and immune to a CDN or upstream path changing under you, which matters for a README you want to still work in three years.
Either way, always set width and height and always write real alt text. GitHub renders READMEs on both light and dark themes, so check your logos against both; this is the most common reason a README logo row looks broken for half your visitors.
When a variant does not exist
If the technology you need is not in Devicon, or the variant you want is missing, check in this order:
- Simple Icons, via the brand logos set. It is monochrome only, but its coverage of company and product marks is broader.
- Tabler's
brand-icons, useful when you want the logo drawn to match your UI icon set rather than reproduced faithfully. See Tabler. - The company's own press or brand page, which is the authoritative source and often has variants nobody has repackaged.
What not to do is trace it yourself. A hand-traced approximation of a trademark is worse than no logo, both legally and visually.
Why not the icon font
Devicon ships an icon font as well as SVGs. Avoid it for the same reasons that apply to all icon fonts, plus one specific to logos: a font glyph is one colour, so the entire point of original variants is lost. If you are using Devicon for recognisable brand colours, the font cannot deliver that. See SVG vs icon fonts.
Licence and trademarks
Devicon is MIT licensed, so the files can be copied, modified and redistributed, including commercially. As with any logo set, the marks themselves remain the trademarks of their owners, and the file licence does not grant any trademark rights.
For a developer portfolio or a stack page this is uncontroversial: you are describing what you use, which is exactly the descriptive use trademark law accommodates. It becomes a question if you start using a technology's logo as a badge of certification or approval. The licensing guide covers where that line sits.