Jump to content

Icon Generator - Quickly generate icons from SF Symbols

Recommended Posts


Icon Generator

Icon Generator will quickly convert an SF Symbol or Emoji to .png for use in workflows.

It includes some nice options for adjusting appearance including a configurable colour palette.


Download: Alfred Gallery  |  GitHub


(Note: the latter two dependencies can be handled by Alfred if you are installing through the Alfred Gallery)


Start by copying an emoji, or an icon in the SF Symbols app.


Convert it to PNG with the icon generator keyword. The result will be in your clipboard.




Alternatively, select the emoji or icon and use the Universal Action.


You can then paste directly into Alfred.


Hold option when running Icon Generator to configure the icon's appearance








Edited by Floating.Point
Update usage to reflect new version
Link to comment

Nice! I know people who’ll be really happy to have this. Ping @Chris Messina, because you mentioned something like this before.


@Floating.Point I’ll encourage you to share this on GitHub, so you can get contributions. We have a tutorial on the blog. Feel free to ask if something is unclear.

Riffing ideas:

  • A feature¹ to simply save the icon (e.g. to the Desktop) because there are situations² where one does really need the icon as a file.
  • Generating icons with a coloured border, to make sure it will always be legible in light and dark themes.³
  • Auto-generating all the icons and showing them in a Script Filter or prepopulating a List Filter so they can be searched from Alfred’s window.

Suggested fixes:

  • In your workflow’s directory, you have extraneous images.
  • The way you’re referencing output.png means it’s using a path relative to your workflow directory and you’re not deleting the image, meaning the last icon will always end up there. Instead, prepend /tmp/ to the path. As in: /tmp/output.png. Though better to make it a more unique name, like /tmp/neigh.alfred.icon_generator.icon.png so it doesn’t conflict with other scripts.⁴

Naturally, all of this is optional, it’s your workflow. If you do share it on GitHub, please do let us know. I can help with those.


¹ Perhaps as a modifier (⌘↩) or as a User Configuration Checkbox.

² Example: Script Filter.

³ ImageMagick, which you’re already using, should be able to do it.

⁴ There are other more “proper” ways, but they add complexity.

Link to comment

Hi Vitor,


Thanks for the excellent feedback. Your ideas are all very welcome. I actually have already uploaded to GitHub (see updated post), though I’m not sure I’ve followed best practices there. I’ll review the blog post you linked and try get better acquainted with GitHub. Then I would very much like to address your feedback. These will all be later-things. As it’s very late for me. 

But for now, cheers! 🍻 

Link to comment

I've been working on a nice little update for this workflow inspired by Vitor's ideas. 


I've ran into a little bit of trouble which I have outlined below. For troubleshooting this issue, I have created a branch in GitHub (I think I'm starting to 'get it' with GitHub). Here's the link


I've set the default save location to /tmp/ and provided a new config field, where the user can choose their own location. Now we need unique naming for the outputs, so let's use the symbol itself for the file name. This works great for the first part of the workflow, where the file is generated and saved to disk. But it isn't playing nice with the AppleScript portion of the script, where the file is then copied to the clipboard.


It seems to fall over when transporting the variable out of Alfred and into AppleScript 

set output to (system attribute "output")
set the clipboard to (read (POSIX file output) as  {«class PNGf»})


It's interpreting the output as


instead of



But if I hardcode the file path, like below, the AppleScript handles the file copy perfectly fine:

set the clipboard to (read (POSIX file "/Users/nathan/Desktop/􀛸.png") as  {«class PNGf»})


So if anyone can help get around that hiccup, the overall workflow is coming together pretty nicely.  It's actually super fast using Alfred's universal actions. Just select the symbol in the SF Symbols app, invoke Alfred's actions menu, and execute the workflow. Bam! Icon ready to go. One could even assign a hotkey / temporary macro if they needed to make a bunch of these.


I still need to explore ImageMagick further, for stuff like generating an outline, and I think I'd like to provide the option to choose a background colour and then generate a filled squircle using this colour, along with a drop shadow. Future features 😊 


Overall, it's really fun working on something that I hope might be useful for others.



Edited by Floating.Point
Added screenshot (because I like pictures and words often fail me)
Link to comment

Clever! But yes, you should avoid filenames with non-ASCII characters¹. Try to support them when you need to take user input (unpredictable), but when you have the control it’ll save you a lot of headaches to avoid them.

Even spaces can be problematic. For example: shells separate arguments by spaces which means you should always quote your variables. This applies to your first script filter, where you should have "$1" and "$output", otherwise spaces in those variables can mess up what you’re trying to do.


If you can extract the symbol’s name, that would be optimal. Otherwise make a unique name with the suggestions above.

If you really want the icon as the name, you can first save it to a temporary location, do what you have to do, then move it to the final destination with the icon name. Or try to work out the (likely) Unicode issue that is causing the original problem. I would recommend neither, at least before the rest of the Workflow is exactly as you want.²

Extra note: On GitHub you have the packaged workflow in the releases section (good!) but then have a repeat of it together with the README. The second one is redundant and won’t allow you to properly review submissions. Instead the recommendation is having the packaged workflow as a release, then the contents of the workflow directory in the repository itself. How the latter is organised is up to you, I keep everything in a Workflow directory. As an example, see the official Shortcuts workflow



¹ And even then, only a subset: _, 0–9, A–Z, a–z, no diacritics.

² Especially the second one. Dealing with text encoding issues can get frustrating.

³ Any of the official workflows, really. They all follow the same structure.

Link to comment

I love avoiding headaches and have happily implemented {random:UUID} instead of pretty, though devilish, non-ASCII characters. I've also taken on board the imperative to quote variables to avoid problems around spaces. Finally, I understand your guidance around how to best author Alfred workflows on GitHub.


So, I'll finish up the current fixes; restructure the repository; and merge the branch into Master (as a point revision).

Hopefully I'm getting terminology here somewhat correct and Ill carry on with it :)


Thanks again Vitor!

Link to comment

I think there might be a way to globally change the colour of all generated icons. We could use ImageMagick to search through all images in a folder, and where it finds single colour icons, it could update the RGB value, leaving the alpha channel in tact. Then we would have a way to update all monochrome icons within our Alfred Environment.  


If anyone is handy with ImageMagick and would like to contirbute, I could use some help (either here, or I've also started a discussion over in ImageMagick land).


The script should run along these lines:

1 Recursively search a directory.

2 Identifying all images that only contain one colour (+ alpha).

3 Replace that one colour with a new value (leaving the alpha as is).

4 Save over the image file.


I think I've found some leads for finding single colour images and for replacing RGB only … but I'm out of my depth for bringing this together into a single script as outlined above.

Edited by Floating.Point
Link to comment
  • 1 month later...
  • 8 months later...

I have updated Icon Generator to support emoji. Alfred will detect if an emoji has been picked and then use the Python module Pillow to generate the icon.


To get this working I needed to install Pillow into Alfred's default Python (/usr/bin/python3) via the following command:

/usr/bin/pip3 install Pillow


@vitor Sorry to ping you directly, but I am not sure how best to deal with this regarding the  Alfred Gallery.


I have 2 ideas about how to handle this gracefully.


1) Include some kind of error handling in Python which pipes back into Alfred, alerting the user they are missing the new dependency.


2) Somehow include the actual Pillow module itself inside the workflow, so the user doesn't even need to think about it.


But I'm not sure which way to go? or is there a better way to handle this.


Otherwise, the updated workflow is really nice. It's a great enhancement. I have added it to Github as a prerelease in case you'd like to test it out.


Link to comment

The way to go is (almost) always to ship the dependency with the workflow. Pillow is so far the exception because it has unsigned binaries which cannot be removed. But telling users to run the pip command themselves is to be avoided. However, Pillow is available in Homebrew so it can be added as a dependency in the Gallery that way, that’s the way to go. @BenjaminO will be the best person to help you there; Emoji Wine uses that solution.

Link to comment

Thank you Vitor


I believe I have now successfully adjusted the workflow to remain compliant with the Alfred Gallery. To do this I changed the Run Script's language from usr/bin/python3 to /bin/zsh--no-res and am now calling an external Python script via the following command:

python3 emoji_to_png.py "$glyph" "$output"


If I am not mistaken, this should allow you to add Homebrew dependencies through the gallery.


I have released another pre-release, and with your blessing I will release as 'latest' so we can get it into the gallery.


Finally, here is an additional screenshot to add to the gallery page, demonstrating the added functionality.



Link to comment
  • 8 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...