A designer often exports a set of icons as SVGs from a design tool, which is ideal for scalability, but a development team's actual implementation needs can vary — some contexts want SVG directly, others need PNG at specific fixed sizes, and older or more constrained systems sometimes need something else entirely. Converting a handed-off icon set into exactly what a specific implementation needs avoids back-and-forth between design and development.
Steps
- Confirm with the development team exactly which format and sizes they need for the specific context — a web icon font, individual PNG assets, or SVG used directly in code, for instance.
- If SVG is needed directly, the designer's original export is often already suitable, provided it is clean vector output.
- If fixed-size PNG assets are needed, export each required size directly from the SVG using SVG to PNG, following the same general approach as our guide to preparing app icons in every size an app store needs.
Why clarifying requirements before converting saves rework
Converting an entire icon set to the wrong format or sizes, only to discover the development team actually needed something different, wastes both the conversion effort and the time waiting for a corrected version. A brief conversation confirming exact requirements before starting the conversion work is almost always faster overall than converting first and adjusting afterwards based on feedback.
Naming converted assets in a way developers can use directly
A consistent, predictable naming pattern for the converted icon files — matching whatever convention the codebase already uses, if one exists — saves the development team from needing to rename every file individually before use. If you are not sure what convention to follow, asking directly is worth the small interruption, since a well-named asset set is considerably faster to actually integrate.
Keeping the original SVG source alongside any raster exports
Even when a specific implementation calls for PNG or another raster format right now, keep the original SVG source files accessible, since a future need — a different size, a different context, a design change — is far easier to address starting from the scalable vector source than from an already-rasterised export.
Handling icons that need to work across light and dark themes
If the interface supports both a light and dark visual theme, icons sometimes need separate versions with different colours or an inverted treatment for each. Check with the design and development team whether this applies to your specific icon set, and prepare and clearly name separate light-theme and dark-theme versions if so, rather than assuming one version works for both.
Converting a whole icon set efficiently, not one at a time
If a handoff includes many icons, process them as a consistent batch rather than one at a time with individually varying settings, so the resulting set is uniform in size, quality and naming convention across every icon, which matters for a cohesive interface just as much as it matters for the design work itself.
Checking the converted icons actually render correctly once implemented
Once converted assets are handed over and implemented, it is worth a quick visual check of the actual result in context — a converted icon can look correct in isolation but display at an unexpected size or with unexpected spacing once placed into the real interface. Catching this early, while the change is still fresh, is easier than tracking down an inconsistency later.
Communicating naming and sizing clearly to developers
Alongside the converted files themselves, a short note listing each icon's intended name and size makes the developer's job considerably easier than leaving them to guess from file names alone. Consistent naming across the whole icon set — matching whatever convention the codebase already uses, if you know it — avoids a round of back-and-forth clarification after handoff, and shows the developer you've thought about how the files will actually be used, not just how they look.
Providing more than one size where scaling matters
For icons that will be displayed at multiple sizes across an interface, providing a couple of pre-sized exports rather than a single large one and expecting the developer to scale it themselves generally produces a cleaner result, since scaling down a small, detail-heavy icon can sometimes lose clarity that a purpose-sized export wouldn't.
Double-checking transparency is preserved through the conversion
Icons typically need a transparent background to work correctly across different interface backgrounds, so after converting, confirm transparency has been preserved correctly rather than accidentally flattened to a solid colour, which is an easy detail to miss in a quick visual check but immediately obvious once the icon is actually placed in the interface.
Frequently asked questions
Should icons always be handed off as SVG?
SVG is generally the best master format for icons given its scalability, though the specific implementation may still need raster exports at fixed sizes depending on the technical context.
What sizes should I export PNG icons at?
This depends entirely on where and how they will be used; confirm the specific required sizes with the development team rather than guessing.
Does converting SVG to PNG lose any quality?
Not if exported directly at the target size from the vector source; quality loss mainly occurs if you resize an already-rasterised PNG down further rather than exporting fresh from the SVG each time.
How do I handle icons that need different colours for different themes?
Prepare and clearly name separate versions for each theme if your interface requires this, checking with the design and development team about which icons need it.
Should I convert the whole icon set at once, or as each icon is needed?
Converting the whole set at once, in a consistent batch, generally gives a more uniform result and saves repeated individual conversion work later.
What if the development team's requirements change after I have already converted everything?
Since you kept the original SVG source files, re-exporting to new requirements is a relatively quick task rather than starting over from scratch.
Is the tool free and private?
Yes. No sign-up, no watermark, and files are removed from the server automatically about an hour after processing.