CMS • 14.05.2025
CMS
Icons in Storyblok: from technical name to visual choice
11 augustus 2026
Picking an icon shouldn't be more complicated than clicking the icon you need. Yet that's exactly what happens in a lot of CMSs: editors aren't clicking an icon, they're clicking a name some developer picked at some point. We thought Storyblok could do this differently, with a custom icon field that lets editors choose icons visually.
Why a name isn't the same thing as an icon
In many CMSs, editors get a dropdown full of names like analytics, shield, or arrow_outward. That works fine technically, the value lands in the field and the site shows the right icon. For the editor updating content day to day, it's a lot less pleasant: they first have to figure out which name matches which icon.
That name usually comes straight from the icon library developers use, not from how an editor thinks about content. To a developer, "arrow_outward" is a clear, technical term. To an editor building a button with an arrow in it, it's just an arrow. That gap shows up in almost any field that exposes a raw technical value: it makes sense to whoever writes the code, and it's a puzzle to whoever fills in the content.
The dropdown: it works, just not for the editor
Say you're adding a new feature to a page and want an icon that says "security." In a dropdown, you first need to know what that icon is called. Is it "security," "shield," "verified_user," or something else? You can try the options one by one, but at that point you're mostly guessing, and you won't find out if you guessed wrong until the page is live and the icon isn't what you had in mind.
That's odd, because icons are about as visual as content gets. Pick a color, you want to see the color. Pick an image, you want to see the image. Pick an icon, and you'd expect to see the icon too, not the internal name it's stored under.
This is where a large library really bites. A website easily ends up with dozens of icons: arrows, a search icon, a hamburger menu, icons scattered through forms. All those names sit in one long list, sorted alphabetically or, worse, in the order they were added. An editor looking for a simple checkmark has to wade through names like "check_circle_outline", "done_all", and "task_alt" to figure out which one actually looks right. At that point it's not content work anymore, it's digging through code.
The icon picker: click on what you see
Instead of a dropdown, editors now get a grid of the icons they're allowed to use on the site. No list of cryptic names, just the icons themselves. You open the picker, look at what's available, and click the icon that fits the content. The choice saves straight to Storyblok, and the site automatically shows that same icon.
The picker also only shows icons meant for content. Technical UI icons that have no business in a feature or callout are simply left out, so an editor never has to scroll past a pile of irrelevant options.
The real payoff shows up once icons appear in more than one place. A feature can have an icon, but so can an accordion item, a USP, or a callout. Without a central solution, every component ends up with its own list and its own behavior. With the custom field, all of those components share the same picker, so once you know how it works in one place, you know how it works everywhere.
A small field, a big difference
An icon picker isn't a big feature on its own. Nothing changes about what's stored under the hood, and the site still shows the same icons it always did. The difference shows up in what the editor actually deals with: no more memorizing icon names, no docs to pull up, no publishing a page just to check if the guess was right.
That's exactly the kind of improvement we look for in a CMS setup. The big, visible features get the attention, but it's the small fields someone uses ten times a week that actually make the difference. A dropdown full of internal names hands the editor a piece of the technical implementation. A visual picker takes that away, so people can focus on the content instead of the CMS.
Want to know how we set up Storyblok to fit the people using it day to day? Get in touch.
