Professional Icon Delivery Workflow
Updated on
Delivering icons professionally is not just about getting the artwork right. The handoff matters too. File structure, export format, naming and documentation all shape how quickly a client or development team can use the assets without coming back for clarifications.
Start with the delivery brief
Before preparing anything, confirm what the recipient actually needs. Web developers usually want SVG files, sometimes alongside an SVG sprite. Mobile teams need platform-specific formats and multiple resolutions. Desktop application teams may ask for ICO files for Windows or ICNS for macOS. Designers often want source files in Figma, Sketch or Adobe formats. Marketing teams are usually after PNG files at specific sizes for different platforms.
A short conversation here saves rework later. It also avoids the familiar mess where someone exports a tidy set of files that nobody can actually use.
Get the source files in order before export
Source files should be tidy enough that exports are predictable and edits do not turn into a slog. If the icons were generated or referenced using AI image tools - for a comparison of the leading options, see Grok Imagine vs Midjourney vs Flux vs Dall-e 2026 - expect extra cleanup work to remove artefacts and normalise paths before delivery. That is the reality, not the brochure version.
Before exporting, flatten unnecessary groups and layers, remove hidden or unused elements, keep artboard sizes consistent across the set, check that colours use the correct colour space (sRGB for web), verify stroke settings are consistent across width, caps and joins, and convert text to outlines if fonts are not being delivered. None of that is glamorous. It does make the handoff easier to maintain.
Well-organised source files also make later updates less painful. Recreating an icon from scratch because the master file is a tangle of stray layers is the kind of admin nobody misses.
Export settings that hold up by format
Each format has its own quirks, and treating them all the same is where delivery starts to go wrong.
SVG export
Use presentation attributes rather than inline styles where possible. Remove unnecessary metadata such as editor information and comments. Keep viewBox attributes so scaling behaves properly. Simplify paths where it does not damage the shape. Decide whether fonts should be embedded or converted to outlines, because that choice affects portability.
PNG export
Export at 1x, 2x and 3x for responsive and retina support. Use PNG-24 for icons with transparency. Optimise file size with tools like TinyPNG or ImageOptim. Name files clearly, for example icon-name-24.png and [email protected]. Clear naming sounds dull until a folder contains twenty near-identical exports.
ICO export
Include multiple sizes in a single ICO file - 16, 32, 48 and 256 are the usual set. Test the ICO at each size so you can catch blur or clipping before handoff. Tools like IcoMoon or dedicated ICO exporters are the practical route here.
Keep the folder structure boring and useful
Delivery folders should be obvious at a glance. A sensible structure looks like this:
delivery/ ├── svg/ │ ├── optimised/ │ └── source/ ├── png/ │ ├── 16/ │ ├── 24/ │ ├── 32/ │ ├── 48/ │ ├── 64/ │ └── 128/ ├── ico/ ├── source/ │ └── icons.fig (or .sketch, .xd) ├── sprites/ │ └── sprite.svg ├── README.md └── LICENSE.txt
That layout lets recipients find the right file without digging through mixed exports or guessing which version is current.
Write the README like someone will use it
A README file should cover the icon list, the formats included, usage guidelines, technical specs, the changelog and contact information. The details matter. Names and brief descriptions tell people what each icon is for. The folder map tells them where to look. Usage guidelines should cover recommended sizes, spacing and colour usage. Technical specs should note the base size, stroke width and corner radius. The changelog should show what changed from the previous version. Contact information gives them somewhere to go when a file does not behave as expected.
Good documentation cuts down on support requests and helps teams implement icons correctly the first time. It also makes the delivery look considered rather than improvised.
Check the package before it leaves your desk
Run a proper quality check before sending anything out. All icons should be present and named correctly. File sizes should be reasonable, with optimisation applied where needed. SVGs should render correctly in browsers. PNGs should have proper transparency, with no white artefacts. Icons should align to the pixel grid at the intended sizes. Colours should match the specification. Documentation should be complete and accurate. The licence file should be included.
Testing deliverables avoids the awkward back-and-forth that happens when a handoff lands half-finished.
Version control belongs in the workflow
Icon sets change over time, so version control needs to be part of the process. Use semantic versioning such as 1.0.0, 1.1.0 and 2.0.0. Document what changed in each version. Think through how updates affect existing implementations. Provide migration notes when the change breaks compatibility.
If clients will receive ongoing updates, set a clear process for delivering and communicating those changes. Otherwise the archive turns into a guessing game after the first revision cycle.
Revision requests without the chaos
Revisions are normal. The aim is to keep them controlled. Keep source files organised so changes are quick. Confirm the scope before starting work. Communicate the revision timeline clearly. Document what changed in the revision. Deliver only the changed files, and label them properly.
Clear communication here prevents scope creep and keeps the project moving. It also stops simple requests from turning into an hour of file-hunting.
Archive the project properly once delivery is done
After delivery, keep the complete project archived. Save all source files in their final state. Keep a copy of what was delivered. Note any special requirements or decisions. Store client communication about the specifications.
Good archives make future updates possible months or years later. Without them, even a straightforward change can become a tedious rebuild.