• Simple to use and easy to edit
• Support for svg favicons!
• Review generated favicons, sizes, information and settings on the same page
• Good defaults with a range of advanced settings (if you need them)
• No third party scripts or sites
• No need to ever paste in markup again once you set up FaviconMagic
• Automatic generation of maskable icon and Lighthouse-friendly manifest, suitable for PWA

Please note: to take advantage of all FaviconMagic functions, imagick must be enabled.
It will work without it, but performance and functionality is more limited.

FaviconMagic takes many of the best ideas and principles of realfavicongenerator (which has always rocked) and implements improvements on them in a seamless processwire environment.

Generating favicon variations is based around manipulating your svg source and outputting once resized, with fallbacks for png.

It's much more than a "clone" of realfavicongenerator: minor annoyances are eliminated, workflow is smoothed and smarter automatic options are implemented. The goal is to provide bang for buck: use the best favicons for modern browsers, while allowing crisp, low-bandwidth fallbacks for others.

This is achieved by threading the needle between what browsers "expect", and what we want to give them.

• Benefits of Favicon Magic

  • Smarter Automagic choices
  • Automatic cropping where appropriate
  • Automatic inclusion of markup for svg icons
  • Automatic generation and inclusion of markup for adaptive maskable icons

• Using FaviconMagic

• Advanced Settings

  • Hide favicon stuff away in a folder
  • Place favicon.ico at site root
  • Use relative links
  • Compress as PNG-8
  • Manifest name and extension

• Example of encouraging browsers to choose the "right" favicon

By design, both the favicons that are generated and the separate folder containing a text file of the favicon markup are independent of the module. Even if you delete the module, your favicons and webmanifest will continue working until you make deliberate changes.

You don't need to touch a zip file, copy/paste new markup or worry about missing files.

FaviconMagic takes care of all the favicon generation, creates a folder, web manifest and browesrconfig and generates the markup for you. Upload your image or images, add a couple of names and your theme color, check the results, click save and you're done.

▲ back to Table of Contents

Wherever possible, choices that are likely to be the same for multiple devices are defined in one place.

There is no good reason to paste the same hex code in multiple places to set the same color for Android, Apple and MS Tiles. FaviconMagic won't make you do that.

The same principle applies to things like app names and manifest short names — they're all roughly the same size, so FaviconMagic will automatically use one, with the ability to over-ride it if you need to.

FaviconMagic makes logical assumptions to simplify workflow and remove complexity. Naturally, these can be over-ridden in Advanced settings if you want to fine-tune performance for a specific device.

In addition, FaviconMagic module config allows you to specify fields from your database to use for different inputs. If you have a field like business_Name, pick the field and FaviconMagic will use that.

You can take this a step further and make things easier over multiple sites. Assuming you use consistent naming patterns, you can add links to your database fields in the getDefaults() array of ProcessFaviconModuleConfig.php, using something along these lines:

'symlink'        => ( $this->config->customFilesAlias ) 
                    ? $this->config->customFilesAlias 
		    :'',			 
'themeColor'     => ( $this->pages->get("/settings")->business_Color ) 
                    ? $this->pages->get("/settings")->business_Color
		    : '',
'businessName'   => ( $this->pages->get("/settings")->business_Name ) 
                    ? $this->pages->get("/settings")->business_Name
		    : '',
'businessDesc'   => ( $this->pages->get("/settings")->business_Blurb ) 
                    ? $this->pages->get("/settings")->business_Blurb
		    : '',
'androidAppName' => ( $this->pages->get("/settings")->business_Abbreviation ) 
                    ? $this->pages->get("/settings")->business_Abbreviation 
		    : '',

▲ back to Table of Contents

2 or 3 pixels off either side makes a very big difference when you only have 16px to begin with. Smaller icons, such as 16x16 and 32x32, are automatically cropped and resized.

Automatically removing empty background allows them to fit the available canvas, so you can provide decent padding at large sizes while still maximising impact at small sizes.

This means you don't need to worry about padding and/or providing multiple resized versions for different sizes.

If your source image is svg, FaviconMagic will automatically generate Markup for your svg favicon.

FaviconMagic will automatically generate an adaptive maskable icon and add markup for it to for your webmanifest.

The adaptive maskable icon cannot be transparent. It is generated with a background color based on your theme color and safe space automatically calculated.

No hassles, no worry, no need for special fussing unless you want to.

▲ back to Table of Contents

1. Install the module
2. Choose your source file and an optional silhouette/mask svg
3. Add a couple of names and your theme color
4. Click Generate New Icons
5. Include the favicon markup in the <head> of your template/s

Ensure your markup always stays up to date by copying and pasting the code below in the <head> of the template/s where you want your favicons, web manifest and browserconfig to appear.

<?php include($this->config->paths->files . 'faviconMarkup/faviconMarkup.txt') ?>

The markup this include links to is automatically generated and saved as a text file to the faviconMarkup folder to ensure your favicon markup keeps working even if this module is deleted.

This is a one-time thing and is the last time you'll need to copy/paste anything to do with markup.

Like a lot of things with FaviconMagic, you could choose to copy and paste the generated favicon markup code to the <head> of your document if you prefer.

We don't recommend that. The include method is simply more robust and more flexible: if something important changes, it changes.

▲ back to Table of Contents

Advanced Settings are shown by default when the module is initially installed but can easily be hidden once you are happy with them. Naturally, they can be accessed and altered at any time.

These include:

• Place favicons in a separate folder — or dump all favicons in site root instead
• Place favicon.ico in site root — or force browsers to download a useless favicon.ico
• Choose name of favicon folder — defaults to 'favicons'
• Choose name and extension of your manifest — defaults to manifest.json
• Input custom name of symlink to /site/assets/files/ if it exists, to use in links
• Use relative links — or choose absolute if you prefer
• Save PNG favicons as indexed PNG-8 — or use larger 'normal' PNG
• Option to specify device-specific colors and names

There is no real benefit to scattering all your favicon variations, browserconfig.xml and web manifest around the root of your site.

With the exception of favicon.ico, which we deal with separately because it acts according to the arcane historical rules and mystical rituals of favicon.ico, there is no performance gain and no efficiency gain. It just makes your site root unnecessarily cluttered.

While we enthusiastically recommend using a separate folder for your favicons, choosing to dump them all in site root instead is as easy as clicking off this option. If you decide later that you're tired of favicon-related clutter in your site root, click it on again and FaviconMagic will clean up the unnecessary files for you.

▲ back to Table of Contents

Regardless of where other favicons, browserconfig and webmanifest are placed, it is much better to place favicon.ico at the root of your site. The alternative is to direct browsers to your favicon through the old shortcut meta tag.

Because of the ancient and weird ways of favicon.ico, this is not great.

If you include the link to favicon.ico, browsers will obediently download it — as instructed — even when they have no need for it and no intention of using it. In contrast, if it is sitting in the site root — where by the arcane rules of favicon.ico, browsers expect it to be — they will happily ignore it unless it is needed.

This is handy, especially when chromium-based browsers like Chrome, Edge, Brave, Opera and many more, consistently request a no-cache version of favicons (cache-control: no-cache).

So, in a nutshell:

1. Unless favicon.ico is in the root with no link, and
2. Unless you are using a service worker, and
3. Until the service worker kicks in,

— then every different page will be downloading the same, unused favicon.ico, for no good reason.

Long story short: place favicon.ico in the site root and there's a decent chance it will never be requested, unless it is needed.

▲ back to Table of Contents

Absolute links include the full domain name of your site with every link to a file. For example: https://www.domainname.com/folder/subfolder/filename.ext

Relative links show only the path to the file from the site root (domain). For example: /folder/subfolder/filename.ext

Given the browser knows where your root is (because you are there) absolute links are not necessary.

Manifest, browserconfig and links to favicons all work the same whether they are defined as relative or absolute links. The choice is largely a matter of preference and/or company policy.

Defaults to relative because the links are simpler and smaller. Changing is as simple as toggling this option on or off, whichever you prefer.

▲ back to Table of Contents

PNG-8 is an 8-bit PNG. This means it can display up to 256 colors, rather than the 16,777,216 available to a 24-bit PNG-24.

In practice, 256 colors with dithering is usually enough to preserve quality at the size of favicons, even when gradients are featured.

Even at 512px x 512 px, there are only 262,144 pixels in the entire image. So even if every pixel of the image was a different color, 16 million+ available colors could not be used.

Like PNG, PNG-8 uses lossless compression.

Unlike 'normal' PNG, PNG-8 only supports a single alpha channel (transparency). For this reason, if your source contains lots of different levels of opaqueness, PNG-8 may not be ideal. That said, we recommend trying PNG-8 first.

This option crunches png icons and the bitmaps used to create favicon.ico with very minimal quality loss. Technically, it removes unused colors and saves the image as an indexed, dithered PNG-8 while preserving an alpha channel for transparency.

Results are usually excellent, with considerably smaller file sizes and little or no visible loss of image quality and clarity. It generally handles gradients well, especially at the size of favicons.

For example, using PNG-8 to create favicon.ico, the expected size is almost halved: around 7.5 kB (safely under 10 kB even if uncompressed for server transfer), compared to around 14.5 kB for a favicon containing 16x16px, 32x32px and 48x48px variations.

This means that even if your server or CDN does not support compression for transfer of .ico files (they should, but some don't), the file size of favicon.ico will still be < 10kb.

Reducing unneccessary data and bandwidth use is always good. As a happy by-product, automated testing tools won't nag you about your oversized favicon, even if your server doesn't allow the use of brotli/gzip for .ico

If the favicons generated with PNG-8 are not up to scratch, try it again without PNG-8 in a single click.

▲ back to Table of Contents

According to the specifications, the "official" extension for your web manifest "should" be .webmanifest. Regardless of whether it is .json or .webmanifest, browsers treat both as JSON and will work properly.

Because the spec is relatively new, some web hosts will not automatically recognize .webmanifest.

Generally epeaking, it's not too complicated to add the .webmanifest info to your htaccess.

It's not hard to add types and encoding, it's just an added item to do.

You might end up with something like this in your htaccess:

AddDefaultCharset UTF-8
AddCharset UTF-8 .webmanifest
DefaultLanguage en
AddType application/manifest+json .webmanifest

Unfortunately, some hosts — like Siteground, for example — no longer allow the option to add new file types with htaccess to their automatic default brotli/gzip transfer compression.

While the file is tiny either way, if warnings about your web manifest not being compressed and/or the added inconvenience of adding type and default character encoding for .webmanifest do not appeal, then .json is a very solid alternative, that works out of the box.

Of course, some online testing tools will flag your use of .json as an issue because it is not the newly "correct" extension for your web manifest.

Either way, browsers treat the info as JSON, so in a perfect world none of this would even be a thing worth considering.

▲ back to Table of Contents

If we markup an old-school shortcut link to ye olde favicon.ico, chromium-based browsers will obediently download it, via a no-cache request. They won't use it, but it will be downloaded repeatedly on every page unless prevented by your service worker or CDN.

Similarly, chromium browsers will try to download a 192x192px favicon from your web manifest, even when they already have a tiny svg which looks great no matter how big it is.

It's not unreasonable to want Chrome, Edge, Brave, Opera and others to see the web manifest and download the tiny favicon svg, instead of the larger 192x192 png the chromium-based browsers request by default. Not a game-breaking bandwidth hog, but mildly annoying when every byte counts: around 15kb for a non-scalable png versus less than 2kb for an infinitely scalable, infinitely crisp svg.

The FaviconMagic web manifest answer to this:

1. Declare your svg last , after all your pngs — last one that is *suitable* size *must* get the nod.
2. Declare the following sizes for your svg — "sizes": "48x48 72x72 96x96 128x128 150x150 256x256 512x512 1024x1024",

Setting 192x192 for your svg size doesn't achieve the desired result as it can mess up app start pages by using the maskable favicon instead.

Happily, the addition of the unusual 150x150 size works well:

• 192x192 is downloaded only when needed and svg is used otherwise
• maskable is used for app icons, rather than app start page, where the extra padding is not ideal for the available space

With favicon.ico in the root, and the correct size definition on your svg, chromium browsers download the same tiny svg twice (because of their no-cache request), instead of downloading the svg, favicon.ico and the 192x192px favicon. It has no effect on what the browers can display, they have no need for the last two.

In the event someone wants to add your site as an app with a Chrome shortcut on their Windows 7 machine, Chrome will happily oblige and get favicon.ico when it is needed.

More relevant in the modern world, threading the needle with this size declaration for your svg results in Android app start screens looking fancy, with a nice large favicon instead of the sometimes unnecssarily small maskable option.

FaviconMagic takes care of this stuff for you, so you don't have to.

▲ back to Table of Contents