Selling icon packs as downloads: the set your buyer judges one 16-pixel icon at a time

Most download sellers ship one product per purchase. An icon seller ships hundreds, and the buyer judges all of them by the worst one — usually the smallest one. Your listing shows the set large, on a clean grid, in your best colour. The buyer drops the icons into a real interface at 16 or 20 pixels, in a toolbar next to system icons you did not draw, in dark mode at midnight. If one icon's stroke is heavier than its neighbours, if one metaphor reads wrong at small size, if the file they need is named something they would never search for, the whole set feels amateur — and a set that feels amateur in one project never gets bought for the next one. The craft is not drawing icons. The craft is consistency, naming, and updates that do not break projects already shipped.

The product is a system, not a folder of pictures

Say in the listing, in plain words, exactly what the buyer gets: how many icons, in which formats, at which sizes. SVG is the working format designers expect — it scales, it recolors, it weighs almost nothing. If you also ship PNGs, name the exported sizes (16, 24, 32, 48, and the retina multiples) and say whether they are exported from the same masters. A pack that ships only PNGs at one size is a screenshot of a product, not the product.

State the construction rules too, because professional buyers shop by them: the grid the icons are drawn on (24×24 is the common contract), the stroke width, corner radius, and whether icons are stroke-based, filled, or both. Two variants of every icon doubles the file count and halves the confusion — a buyer who has to hand-convert your outline set into a filled set will do it once and buy someone else's next time. Whatever you ship, ship all of it in the same system: one grid, one stroke, one set of metaphors. A pack of 300 icons drawn in three styles is three packs of 100 wearing a trench coat.

Small is the real size: the 16-pixel test

Icons live small. The sizes in your preview — 48, 64, 96 pixels — are marketing sizes; nobody's sidebar renders at 96. Every icon in the set has to survive the sizes it will actually be used at, and detail that reads beautifully large turns to mud small: a shopping cart with individual spokes, a gear with twelve teeth, a face with two eyes and a smile.

Do the test before you sell, and say in the listing that you did it: place every icon at 16 and 20 pixels, in a row, at arm's length, and squint. The ones you cannot identify get redrawn simpler — fewer elements, bolder shapes, detail deleted rather than shrunk. This is also where metaphor discipline pays: the icon for "settings" that needs a caption is not an icon, it is an illustration with ambitions. Buyers forgive a plain icon. They do not forgive one they have to explain to their own users.

Consistency is invisible until it breaks

A set reads as professional when nothing about it draws attention: every icon sits on the same grid with the same padding, strokes match to the quarter-pixel, corners share one radius, and the visual weight — how dark an icon appears at a glance — is even across the set. One icon drawn on a 20-pixel grid inside a 24-pixel set will look subtly wrong forever, in every project, and the buyer will feel it without ever knowing why.

Hold the line mechanically, not by eye. Build on the grid and do not nudge off it for one special icon. Use the same stroke width everywhere, including the icons where a thinner stroke "looks better" — it looks better alone and wrong in the row. Check the set the way buyers see it: as a contact sheet, all at once, at small size. The outliers announce themselves. Fix them in the masters, not in the exports, or the next update quietly reintroduces them.

Filenames are the search engine

Inside Figma, IconJar, or a project folder, your icons are found by name or not found at all. A buyer mid-project types "arrow," "cart," "download," "user" — if your files are named icon_042_final.svg, you have hidden your own product from its owner. Name every icon with the words a buyer would search: the object first, then the variant — arrow-right, arrow-up-left, cart, cart-add, user, user-check. Synonyms matter: include the alternate term buyers use (trash and delete, settings and gear) in a searchable index file if your format allows keywords, or in the names of duplicate aliases where the tool supports them.

Keep names stable and boring: lowercase, hyphens, no spaces, no version numbers, no renaming between updates. The filename is an API. A designer's project links to cart.svg; if version 2 renames it shopping-cart-v2.svg, you have broken their file with your improvement, and they will learn to never update your pack again — which is the subject of the last section but one.

Both themes, or say so: the dark-mode line

Half of your buyers' interfaces ship a dark theme, and icons are where dark mode goes to die: a dark-grey outline icon on a near-black background is a rumour of an icon. Decide before launch how your set handles it. Stroke icons in a single currentColor-style colour adapt automatically in code and most design tools — say so plainly if yours do. Filled and multi-colour icons need a tested dark variant: lighter fills, adjusted contrast, sometimes a different shape where a shadow detail disappears.

Then test it the honest way: the full contact sheet on white, on black, and on the mid-grey that real sidebars actually use. If you only ship a light-tested set, write that on the listing — "tested on light backgrounds" is an honest product; the same set sold theme-silent is a support thread and a refund. Buyers who build dark interfaces are often your best repeat customers; they are shopping specifically for a set that has done this work.

The licence line icon buyers actually hit

Icon licensing has one edge case that generates nearly all the disputes: the buyer is not using your icons in a picture of a product — they are shipping them inside a product, sometimes a product other people build on. Spell out the operative lines in plain words, in the listing and in a licence file inside the download: use in commercial projects is allowed, including apps and websites shipped to end users; redistributing the raw icon files themselves — in a competing pack, a freebie bundle, or an open-source repo — is not; whether a buyer may include the icons in a template or UI kit they resell is your call, but it is the question every template seller will ask, so answer it before they have to email you.

Trademark-shaped icons deserve their own line. If your set includes brand logos or near-logos, say what they are for — editorial mockups are a different risk from shipping them in a commercial app — or leave them out of the set entirely. One sentence in the licence file prevents the angriest email in this business: the one from a buyer whose app review was rejected over an icon you drew.

An update that renames is a recall in reverse

Icon sets grow: you add the 40 icons buyers keep requesting, fix the two that failed the 16-pixel test, ship version 2. Everything from the earlier sections now becomes an update policy. Never rename an existing icon in an update. Never change a filename's meaning — cart must keep being the cart. Add new icons under new names, mark deprecated ones in the changelog instead of deleting them, and ship the update as the full set plus a plain-language list of what was added and what changed.

Version the pack and say the version inside the download — a README with the set name, version, date, icon count, and the naming and licence summaries. A buyer who can check in ten seconds whether they hold the current version is a buyer who updates; a buyer who cannot tell will run the old set forever and judge you by it. Announce updates to past buyers with the added-icon list first — for icon packs, "now includes the 40 most-requested icons, nothing renamed" is the whole pitch, and it is a true one only if you kept the discipline above.

A short launch checklist for icon pack sellers

1. Name the contents in the listing: icon count, formats (SVG first), PNG export sizes, grid, stroke width, and whether stroke and filled variants are both included.
2. Run the 16-pixel test on the whole set: every icon identifiable at 16 and 20 pixels, in a row, at arm's length — redraw the ones that fail, simpler.
3. Check consistency mechanically: one grid, one padding rule, one stroke, one corner radius; review as a full contact sheet, and fix outliers in the masters.
4. Name every file for search: object first, variant second, lowercase hyphens, synonyms covered — and commit to never renaming them in updates.
5. Test the full set on white, black, and mid-grey; ship a dark variant or state "light backgrounds only" on the listing.
6. Write the licence in plain sentences, in the listing and inside the download: shipped-product use yes, raw redistribution no, template-resale answered, brand icons addressed.
7. Write the update policy before you need it: additions under new names, nothing renamed or deleted, version and changelog in a README inside the pack.

A note on delivery, because every step above ends at a download: I build FileFreight for sellers of files like these — flat-rate digital delivery with licence keys, where you connect your own Stripe account, Pro is $19/month with 0% platform fees (a free tier takes 5%), sales tax and VAT handling stay with you as the seller, there is no icon importer and no Figma or design-tool integration, and it is not a Shopify app. Whatever you deliver with, judge it by the test in this article: your set has to stay consistent, findable, and unbroken inside projects you will never see — so the delivery has to carry the names, the licence, and the update path with it.