Affinity Studio · SVG · Technical diagrams · Open source · Design systems
Community Icons: consistent icons for technical diagrams
Choose consistent SVG and PNG symbols for technical diagrams, check their catalog hashes and keep the editable artwork for later changes.
- Drafted
- Published
- Updated
- Reading time
- 6 min
- Author
- Roberto Gramellini
Source:
Community Icons
· revision 55e38178
- Community Icons
- Affinity Studio icons
- technical diagram icons
- editable SVG icons
- Apache License 2.0
- Azure architecture icons
Community Icons: consistent icons for technical diagrams
Community Icons is an Apache-2.0-licensed collection of original vector artwork. This article describes the public source at revision 55e3817; the collection version recorded there is 2.1.1.
The diagram with twenty boxes
Twenty rectangles, a few arrows, and “the labels make it obvious.” An architecture review can start like this quite innocently. Then you notice three styles of laptop, a cloud borrowed from a presentation template and a hand-drawn network hexagon. Everyone is reading the labels because nothing else is helping. We could hold another meeting to clarify the diagram, naturally.
Endpoint administrators, cloud architects, security teams and technical writers all need recognizable symbols. Finding devices, identity, network paths, cloud services and AI workflows in a consistent style takes time; drawing everything takes more. Official service artwork is useful when you mean that exact service. For a general concept, a page full of product logos can say more than you intended.
Community Icons provides original, minimalist symbols for this sort of work: diagrams, documentation, presentations and interfaces. You can take a ready-made SVG or PNG, or open the native vector document and adapt the artwork. I'd want both options in a collection I planned to keep using.
One visual system, many technical subjects
At the reviewed revision there are 100 SVG variants, matching PNG exports, nine editable native documents and preview sheets. Read “variants” literally: alternate colours and usage treatments are included. The count does not mean 100 wholly different concepts.
| Collection | What it helps explain |
|---|---|
| Infrastructure 01–03 | Device management and lifecycle; network topology and connectivity; cloud, data and AI concepts |
| Extended services and infrastructure | Forty concepts grouped into Devices, Networking, Azure Services, AI workflows and Cloud Services |
| Section icons | Challenge, outcome and feature sections, including an alternate feature symbol |
| Security: lock and magnifier | Outline and solid treatments for light or dark visual contexts |
| Security: solid Azure exports | Portal and favicon sizes, with light, dark and white-lock variants |
Infrastructure collections use transparent 256 × 256 artboards, sixteen designs in a 4 × 4 grid per native document. Navy and blue (#0F2741 and #0078D4) with rounded strokes keep a device and an AI symbol looking related. The extended-services document is organized differently: five ordered groups of eight artboards. That arrangement makes a larger catalogue easier to scan and export without creating a document for every new idea.
Use the laptop, private endpoint, message queue or model-evaluation symbol to explain a concept. This is a diagram vocabulary; it is not a product UI kit or an attempt to reproduce vendor logos.
From editable artwork to a dependable asset
Getting an asset into a diagram is fairly direct:
- Open the editable source if you need changes. Native
.afdocuments keep the artboards and vector geometry. The reviewed README records version 3.3 of the authoring application, so check compatibility before editing. - Choose an export for the destination. SVG scales for diagrams, interfaces and print. Transparent 256-pixel PNGs work where SVG is unsupported or a raster image is more convenient. Browse the preview sheets first if you are choosing from a whole set.
- Keep the names useful. Subject folders and descriptive filenames organize the symbols; the catalog records the files actually distributed.
- Check the download.
catalog.jsongives each asset's relative path, byte size and SHA-256 hash. Compare those with the indexed release rather than trusting a filename. - Leave enough room to read it. The recommended minimum is 32 pixels, or 48 for detailed artwork. Light security variants belong on dark backgrounds.
Here is the catalog shape, including the information needed for that file check:
{
"version": "2.1.1",
"svg_variants": 100,
"native_documents": 9,
"files": [
{
"path": "sets/extended-services/01-laptop.svg",
"sha256": "249de91b6c3b38ceb2c349174df243db059ff6d4d5671155ad7ec10fa7af646a",
"bytes": 1435
}
]
}
The files live in the repository. The catalog inventories them and supplies integrity metadata; it does not build the artwork or serve remote assets. You can inspect and fork the collection, then integrate selected exports into your own design system.
Figure 1: source artwork, exports and integrity checks stay together. No hosted service is needed.
Keep the editable files too
Placing an icon is usually a job for the SVG. Changing a stroke, fill, artboard group or size variant is easier with the editable source. Keeping it also gives contributors somewhere sensible to start a related concept, without reverse-engineering flattened artwork.
Source documents help with review too. You can inspect an artboard group, make the intended change, export the relevant formats and update the catalog, rather than wonder where an opaque export came from. The README welcomes issues and pull requests. Contributions should include a descriptive name, SVG export and preview, with editable source retained when available.
The native documents are stored directly in Git at this revision. There is no extra package manager or Git LFS client to set up. Download a ZIP with GitHub's Code → Download ZIP or clone the repository, then use a compatible vector editor to open the .af documents.
These are conceptual icons
Some symbols describe Azure-related concepts, but they are independent illustrations, not Microsoft’s official Azure service icons or product logos. They do not imply Microsoft endorsement. Use them to explain a general architecture idea; when a diagram requires official Azure service artwork, download that artwork separately from Microsoft’s official Azure Architecture Icons collection.
I'd use a conceptual icon freely in an overview, but never present it as an exact service mark in a product interface or compliance document. And check it at the size you actually intend to display: the minimum-size recommendations do not promise that a detailed symbol will work as a favicon.
The artwork is distributed under the Apache License 2.0. Before redistributing artwork or modified exports, include the license, retain applicable notices, and clearly mark files you changed as the license requires. The repository’s license file at the reviewed revision is the authority; a link in an article is not a substitute for the license when redistributing the assets themselves.
Try it in your next architecture review
For a diagram connecting devices, networks, cloud services, security controls and AI workloads, I'd start with a preview sheet. Pick exports that fit the destination and keep the native document nearby if you expect to adapt them. A consistent set saves the reader from learning a new drawing style in every box.
Browse the Community Icons repository and catalog.json, or contribute an original symbol through an issue or pull request. The next diagram may still need twenty rectangles. At least the reader can spend less time decoding what is inside them.