Weave Code
Laravel Favicon Laravel Package
beyondcode/laravel-favicon
Generate a complete set of favicons for your Laravel app from a single source image. The package provides an Artisan command and Blade helpers to create and reference favicon files, simplifying setup and keeping your markup clean.
Create dynamic favicons based on your environment settings.
Frequently asked questions about Laravel Favicon
- How do I install beyondcode/laravel-favicon in a Laravel app?
- Run composer require beyondcode/laravel-favicon, publish the package config with vendor:publish, drop one high-resolution square source image into the configured location, then run the package's Artisan generation command and add the Blade directive to your layout head. Integration is measurable in hours rather than sprints. Confirm the exact publish tag and command name against the installed version's README, since those details differ between releases.
- Does beyondcode/laravel-favicon support Laravel 11, 12 and 13?
- Release 1.9.0 is a Laravel 13 compatibility contribution and is the only release claiming that support, so adopt it as your baseline. Before approving, confirm the 1.8.0 to 1.9.0 diff touches only composer.json and CI rather than hiding behavioral change, and check whether a CI matrix actually exercises Laravel 13. The package follows idiomatic Laravel conventions (service provider, publishable config, facade, Blade directive), so it fits the slim bootstrap/app.php structure of Laravel 11 and later as long as the provider is registered normally.
- What favicon files does it generate from a single source image?
- It produces the complete common set: a legacy .ico plus modern PNG variants, the Apple touch icon, and the web manifest entries that reference them. That covers browser tabs, home-screen icons and manifest output from one committed asset. You do not need to hand-export each size or maintain separate icons per platform.
- Does it require the GD or Imagick PHP extension?
- Yes. Image rendering needs GD or Imagick, and the failure appears at first generation rather than at composer require, so it tends to surface in staging or production instead of CI. Many container images ship without GD enabled. Add the extension to your image build or assert extension_loaded('gd') in a test so the precondition is checked early.
- How does favicon caching work, and can I serve icons dynamically at runtime?
- Generation is a build or deploy step, and the results are cached so repeat delivery is fast and consistent. Because the package integrates with Laravel configuration and routing, you can serve icons dynamically without manually editing images for every size. The important thing is to record one explicit decision: are favicons a build artifact or a runtime concern?
- Can I use it when production runs on a read-only filesystem or immutable containers?
- Not as-is. Generated icons are written to a public path, so read-only container filesystems, immutable deploy images and serverless targets break unless generation moves to build time. The practical fix is to run generation during CI or the image build and ship the resulting files as static assets. In that setup the package is a build-time dependency only and never needs write access in production.
- Does it work with Vite and hashed asset filenames?
- It works, but it needs deliberate handling. Favicons are referenced by stable, unhashed public paths, which sits outside Vite's manifest and cache-busting model. Either exclude the icon directory from hashing and reference it through the package's Blade directive, or copy generated icons into public during the build. Make it a recorded decision rather than something discovered during a rebrand.
- How do I test favicon generation in CI?
- Add a test that runs the generation command, asserts a successful exit code, and checks that the expected files exist on a temporary disk path. Also assert that GD or Imagick is loaded, since a missing image driver is the most common failure. This moves the two typical breakages, missing driver and unwritable path, out of staging and into CI.
- Does it support intervention/image v3, and what is the upgrade risk?
- Check the image-library constraint in composer.json before adopting. The likelier future cliff for this package is intervention/image v2 to v3 rather than a Laravel major release, so put that upgrade on the watch list. If the constraint pins v2 only, budget for a fork-and-patch, which the package's small surface area keeps to roughly a day of work.
- What are the alternatives to beyondcode/laravel-favicon, and is it worth adopting?
- Alternatives are a hand-rolled Artisan command (about a day of work), favicon generation inside your existing asset build, or a hosted favicon service. The package wins when your application renders server-side HTML in Laravel and favicons are not already solved by the asset pipeline, hosting layer or CMS. With 375 stars, zero dependents and an MIT license, classify it as a convenience-tier dependency rather than a strategic one.
Weaver
How can I help you explore Laravel packages today?