Favicon-indelingen uitgelegd: ICO, PNG, SVG en wat browsers nodig hebben

Waarom favicons nog steeds vreemd ingewikkeld zijn

Een favicon lijkt één kleine afbeelding, maar bevindt zich op het snijvlak van browserinterface, bladwijzers, tabbladen, vastgemaakte snelkoppelingen, zoekresultaten, mobiele startschermen en installaties van progressive web apps. Elke context heeft net iets andere verwachtingen.

Daarom voelt advies over favicons vaak rommelig. Sommige teams leveren alleen één favicon.ico, omdat dat vroeger genoeg was. Andere genereren een dozijn bestanden zonder te weten welke daarvan daadwerkelijk worden gebruikt. De verstandige middenweg is kleiner: begrijp waar ICO, PNG en SVG elk goed in zijn, en lever daarna een compacte set die huidige browsers en gangbare apparaatcontexten dekt.

Favicons zijn niet de plek om te pronken met een image pipeline. Ze zijn de plek om saai, expliciet en compatibel te zijn.

ICO: het oude formaat dat weigert te verdwijnen

ICO is de klassieke container voor Windows-iconen. Het kan meerdere bitmapafbeeldingen op verschillende formaten bevatten, vaak 16×16, 32×32 en 48×48 pixels. Dat is belangrijk omdat een favicon heel klein kan worden weergegeven in een browsertabblad, groter in een bladwijzerlijst, en weer anders bij Windows-snelkoppelingen.

Het belangrijke detail is dat ICO een container is, niet simpelweg één afbeelding. Een goede favicon.ico bevat meestal meerdere rasterformaten, zodat de browser of het besturingssysteem de dichtstbijzijnde match kan kiezen in plaats van één piepkleine bitmap te schalen.

ICO is nog steeds nuttig om drie redenen:

• Browsers kunnen automatisch /favicon.ico opvragen, zelfs als je er niet naar linkt in je HTML.
• Sommige oudere browsers en integraties verwachten het.
• Het is een veilige fallback wanneer nieuwere iconendeclaraties worden genegeerd.

Dat betekent niet dat ICO je enige icoon zou moeten zijn. Het is lastig te bewerken, niet bijzonder vriendelijk voor moderne workflows en ongeschikt als bron van waarheid voor een merkbeeld. Behandel het als de compatibiliteitsfallback.

Plaats in de praktijk een echte /favicon.ico in de root van de site. Serveer daar geen 404, tenzij je houdt van rumoerige logs en onnodige browserpogingen.

PNG: het betrouwbare werkpaard

PNG is nog steeds het meest voorspelbare rasterformaat voor favicons en touch icons. Het ondersteunt transparantie, wordt breed ondersteund en gedraagt zich consistent in browsers en op platforms.

Voor favicons is PNG nuttig wanneer je expliciete iconen met pixelafmetingen wilt, zoals 32×32 of 48×48. Voor iconen op mobiele startschermen is PNG in sommige omgevingen feitelijk verplicht. Apple touch icons zijn bijvoorbeeld in normaal productiegebruik op PNG gebaseerd.

Een paar praktische regels helpen:

• Exporteer vanuit een vectorbron, niet vanuit een bitmap die al klein is.
• Zorg dat het icoon leesbaar is op 16×16 voordat je je druk maakt om grotere formaten.
• Voeg genoeg padding toe zodat het merkbeeld niet afgesneden aanvoelt in afgeronde of gemaskeerde contexten.
• Vermijd kleine tekst, dunne lijnen en gedetailleerde illustraties.

PNG-compressie is bij favicons meestal niet de moeite waard om je op blind te staren, omdat de bestanden klein zijn. Lever toch geen touch icon van 500 KB omdat het rechtstreeks uit een designexport komt. Als je toch al bredere afbeeldingskeuzes beoordeelt, geldt dezelfde gedisciplineerde manier van denken uit beslissingen over afbeeldingsformaten op het moderne web ook hier: kies het formaat voor de taak, niet omdat het modieus is.

SVG: de moderne, flexibele optie

SVG-favicons zijn aantrekkelijk omdat ze resolutie-onafhankelijk zijn. Eén klein bestand kan op veel formaten scherp renderen, en het kan rechtstreeks in code worden bewerkt of uit ontwerpsoftware worden geëxporteerd.

Moderne versies van Chromium, Firefox en Safari ondersteunen SVG-favicons. Dat maakt SVG voor veel sites een goed primair favicon-formaat, vooral wanneer het icoon een eenvoudig logo, glyph of geometrisch merkbeeld is.

Maar SVG-favicons hebben kanttekeningen.

Ten eerste moet de SVG op zichzelf staan. Vertrouw niet op externe fonts, externe afbeeldingen of scripts. Browsers passen beperkingen toe op SVG die als afbeelding wordt gebruikt, en zelfs wanneer iets in de ene browser werkt, kan het in een andere mislukken.

Ten tweede: houd het visueel eenvoudig. SVG lost het 16-pixelprobleem niet magisch op. Een gedetailleerde vectorillustratie is nog steeds een vlek wanneer die in een tabblad wordt geperst.

Ten derde: wees voorzichtig met dynamische styling. Sommige teams gebruiken prefers-color-scheme binnen een SVG-favicon zodat het icoon zich aanpast aan donkere en lichte browserthema's. Dat kan werken, maar browsergedrag en caching kunnen ongelijkmatig zijn. Als merkherkenning belangrijk is, wint één robuust icoon vaak van een slim adaptief icoon.

SVG is een goede bron en een goed modern leveringsformaat. Het is geen reden om fallbackbestanden over te slaan.

Waar browsers werkelijk naar zoeken

Browsers ontdekken favicons op twee hoofdmanieren: expliciete HTML-links en impliciete rootverzoeken.

Het impliciete gedrag is het oude gedrag: als de browser een icoon wil en er geen heeft gevonden, kan hij /favicon.ico opvragen. Daarom blijft het ICO-bestand in de root nuttig, zelfs op moderne sites.

Het expliciete gedrag gebruikt <link>-elementen in de document-head. Een compacte moderne opzet ziet er zo uit:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

Het manifest kan vervolgens verwijzen naar grotere PNG-iconen die worden gebruikt voor installeerbare webapps:

{
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Dit is niet de enige geldige opzet, maar wel een goede basis. Het geeft moderne browsers een SVG, biedt een conventionele ICO-fallback, dekt iOS-startschermopslag en ondersteunt contexten voor appinstallatie.

De favicon-set die de meeste sites zouden moeten leveren

Voor een normale marketingsite, documentatiesite, SaaS-app of publicatie is deze set voldoende:

• /favicon.ico met 16×16 en 32×32, eventueel 48×48.
• /icon.svg als de moderne schaalbare favicon.
• /apple-touch-icon.png op 180×180.
• /icon-192.png en /icon-512.png als je een web app manifest hebt.

Je kunt meer formaten toevoegen als een platform een specifieke eis heeft, maar genereer geen tien bestanden uit gewoonte. Elk extra bestand is nog iets om te cachen, te vergeten, verkeerd te benoemen of na een rebranding verouderd te laten.

Als je site niet installeerbaar is en geen manifest heeft, heb je de iconen van 192 en 512 pixels mogelijk niet nodig. Als je site zich als een app gedraagt, waarschijnlijk wel.

Veelvoorkomende faalwijzen

De meest voorkomende favicon-bugs zijn niet artistiek. Het zijn leveringsproblemen.

Eén daarvan is agressieve caching. Browsers houden favicons hardnekkig vast. Tijdens het testen verschijnt een gewijzigd icoon soms pas nadat je hard refresht, sitegegevens wist, een nieuwe bestandsnaam gebruikt of in een vers profiel test. Voor rebrandings in productie kan het helpen om /icon.svg?v=2 in HTML te wijzigen, maar de root /favicon.ico is lastiger omdat browsers die rechtstreeks opvragen. Het bestand vervangen en caches laten verlopen hoort vaak bij het werk.

Een ander veelvoorkomend probleem is het verkeerde MIME-type. SVG moet worden geserveerd als image/svg+xml, PNG als image/png, en ICO meestal als image/x-icon of image/vnd.microsoft.icon. Veel browsers zijn vergevingsgezind, maar niet alle contexten zijn dat. Als iets alleen in één browser mislukt, inspecteer dan de netwerkrespons voordat je het icoon opnieuw tekent. Dezelfde gewoonten die je gebruikt bij het debuggen van redirects en HTTP-headers in productie gelden hier ook: kijk naar de daadwerkelijke respons, niet naar wat het CMS beweert te serveren.

Een derde probleem is designdichtheid. Logo's die prachtig werken in de header van een website, falen vaak als favicon. Het tabbladicoon is een genadeloze test. Verwijder woorden, vereenvoudig vormen, verhoog het contrast en test op echte formaten. Als het icoon betekenisvolle content binnen de pagina is, dan zijn toegankelijkheidsaspecten zoals alt-tekst belangrijk; voor de favicon zelf geldt dat het decoratie van de browserinterface is, geen pagina-inhoud. Zie voor dat onderscheid onze praktische gids voor alt-tekst bij afbeeldingen.

<!-- tool-cta:start -->

💡 Probeer dit: Genereer in één keer de ICO-, PNG- en SVG-varianten die moderne browsers verwachten met Ultimate Favicon Generator.

<!-- tool-cta:end -->

Een eenvoudige implementatiechecklist

Gebruik deze checklist voordat je publiceert:

1. Begin met een schone vector-master.
2. Test het merkbeeld op 16×16 en 32×32.
3. Exporteer een op zichzelf staande SVG-favicon.
4. Genereer een ICO-fallback met meerdere formaten.
5. Exporteer een Apple touch icon van 180×180.
6. Voeg PNG's van 192×192 en 512×512 toe als je een manifest gebruikt.
7. Plaats /favicon.ico in de root van de site.
8. Controleer statuscodes, MIME-types en cachingheaders.
9. Test in minstens één Chromium-browser, Firefox en Safari als je publiek Apple-apparaten gebruikt.

Favicons zijn klein, maar ook zeer zichtbaar. Een kapotte favicon laat een site onaf voelen. Een goed gemaakte favicon verdwijnt in de interface, en dat is precies de bedoeling.