Open Graph : tailles, formats et images absentes

La norme 1200×630, et pourquoi

La norme de fait og:image la taille est 1200×630 pixels, soit un ratio d’environ 1.91:1. Ce chiffre n’est pas une tradition arbitraire : il est proche du ratio le plus large des cartes d’aperçu de liens sur Facebook, LinkedIn, Slack et Discord. Une image de 1200×630 remplit donc la carte sans bandes ni recadrage important par la plateforme.

Les petites images fonctionnent techniquement, mais la plateforme les agrandit pour remplir la carte, ce qui adoucit les détails et peut être nettement moins beau qu’une image conçue pour cet usage. La plupart des plateformes indiquent un minimum autour de 200×200 pour accepter une image en aperçu, mais voyez-y un plancher, pas une cible : tout format sensiblement inférieur à 1200×630 sacrifie de la qualité sans avantage.

de Twitter/X summary_large_image utilise la même image 1200×630 et le même ratio ; une seule image convient donc généralement aux deux og:image et twitter:image sans nécessiter d’export séparé.

Zone sûre : ce qui survit réellement au recadrage

Même avec le bon ratio, les plateformes recadrent légèrement la carte différemment selon l’emplacement : une publication du fil, un aperçu de lien en message privé et un module « liens partagés » dans une barre latérale ne montrent pas toujours le même recadrage de la même image. Un texte ou un logo placé au ras du bord peut être coupé sur l’un de ces emplacements, même s’il semblait correct dans l’aperçu de votre onglet.

Le plus sûr est de conserver le contenu essentiel — titre, logo, visage — dans environ les 90% intérieurs du cadre, avec une marge d’environ 5–10% sur chaque bord. Les images de fond, dégradés et éléments décoratifs peuvent aller jusqu’au bord ; seul le contenu que chaque spectateur doit voir doit rester en retrait. Si votre outil graphique le permet, tracer un rectangle de repère en retrait d’environ 60px de chaque côté d’un canevas 1200×630 fournit une zone sûre de travail raisonnable.

Format JPG ou PNG : pourquoi pas WebP

Pour le fichier réel, JPG et PNG sont sûrs. La compatibilité WebP pour og:image en particulier est pris en charge de manière inégale par les robots de collecte et d’aperçu de liens : certains le gèrent, d’autres n’affichent silencieusement aucun aperçu avec un WebP. Ce silence facilite la livraison d’un aperçu cassé sans s’en apercevoir avant qu’un utilisateur le signale.

Cette compatibilité est plus restrictive que fournir du WebP à un navigateur, ce que presque tous les navigateurs actuels gèrent bien ; voir notre Comparaison de WebP, PNG et JPG pour le cas général. Les robots d’aperçu de liens sont des clients différents et plus conservateurs que les navigateurs des utilisateurs, et leur prise en charge de WebP est en retard. Utilisez JPG pour les aperçus photographiques, plus petits à qualité visuelle équivalente, et PNG pour les aplats, le texte ou la transparence à conserver dans certains contextes. La transparence elle-même importe toutefois peu pour une image OG, puisqu’elle s’affiche toujours sur le fond de la carte de la plateforme.

Le GIF est techniquement accepté comme image statique par la plupart des plateformes, mais n’est pas un choix pertinent pour un aperçu photographique ou riche en graphismes. Il n’y a ici aucune raison pratique de le préférer au JPG ou au PNG.

L’URL doit être absolue

<meta property="og:image" content="/og-image.jpg" /> semble raisonnable et fonctionne lorsque vous consultez directement la page dans un navigateur, car celui-ci résout le chemin relatif à partir de l’URL de la page courante. Les robots d’aperçu de liens ne font souvent pas cette résolution de manière fiable, ou utilisent une mauvaise base. Le résultat pratique est une image absente ou cassée sur certaines plateformes alors qu’elle fonctionne sur d’autres, ce qui rend le diagnostic difficile à partir des seuls signalements.

Écrivez toujours l'URL absolue complète, protocole et domaine :

<meta property="og:image" content="https://example.com/og-image.jpg" />

Dans l'API Metadata de Next.js, définissez metadataBase dans la mise en page racine pour que les chemins relatifs des images déclarés dans les métadonnées des pages soient automatiquement convertis en URL absolues à la compilation, ou en écrivant l’URL complète directement dans chaque page, dans openGraph.images entrée comme le fait ce site.

Cache : pourquoi l'ancien aperçu reste affiché

C’est la cause principale de « j’ai corrigé mais c’est toujours faux ». Les plateformes mettent en cache les données Open Graph, image comprise, par URL. Ce cache n’expire pas juste parce que vous déployez un nouveau fichier. Recharger la page, même en navigation privée, ne dit rien du cache de la plateforme.

Chaque plateforme possède un outil de nouvelle extraction :

• Facebook / Meta : le Sharing Debugger (developers.facebook.com/tools/debug/) : collez l’URL et cliquez sur « Scrape Again ». Cela vide aussi le cache des aperçus de liens Instagram et WhatsApp, qui partagent le robot de Meta.
• X/Twitter : le Card Validator remplissait historiquement ce rôle ; sa disponibilité a changé avec le temps. S’il est inaccessible, ajouter à l’URL une chaîne de requête de version inoffensive — voir ci-dessous — est une solution de secours plus fiable.
• LinkedIn : le Post Inspector (linkedin.com/post-inspector/) : collez l’URL pour forcer une nouvelle collecte.
• Slack, Discord, iMessage : aucun outil de débogage public. Ces plateformes laissent généralement expirer leur cache selon leur propre calendrier, ou l’actualisent lorsque l’URL change, même légèrement.

Lorsqu’un outil de débogage propre à une plateforme est indisponible ou récalcitrant, la solution universelle consiste à modifier l’URL que voit la plateforme, en ajoutant une chaîne de requête de version comme ?v=2 au lien partagé ou à l’URL de l’image elle-même force chaque plateforme à traiter la ressource comme nouvelle et à la récupérer plutôt que de servir une ancienne entrée du cache.

Taille et autres limites

La plupart des plateformes documentent une limite de quelques mégaoctets : celle de Facebook a historiquement été d’environ 8MB. Même celles qui ne publient pas de chiffre explicite tendent à dépasser le délai d’attente ou à refuser l’aperçu d’un fichier inhabituellement gros. Comme un JPG ou PNG bien compressé de 1200×630 pour ce type de contenu reste généralement largement sous 500KB, atteindre une limite signifie presque toujours que l’export n’est pas optimisé : une énorme photo réduite dans le balisage, mais pas réencodée aux dimensions plus petites, ou une photographie exportée en PNG plutôt qu’en JPG. Consultez notre guide de réduction de la taille des fichiers image pour la méthode générale de réduction d’un export sans perte de qualité visible.

Lisibilité du texte en vignette

Une image OG s’affiche généralement bien plus petite que ses 1200×630 pixels natifs : un aperçu Slack ou une carte de fil mobile peut n’avoir que quelques centaines de pixels de large. Tout texte intégré doit rester lisible après cette réduction. En pratique, un texte courant inférieur à environ 40px dans une image native de 1200px de large devient souvent illisible une fois réduit pour le fil. Un titre lisible en vignette doit généralement être nettement plus grand, plutôt 60–80px ou davantage, en gras et avec un fort contraste sur son fond.

C’est aussi une raison de garder l’image elle-même simple. Une composition chargée comportant plusieurs éléments de texte concurrents peut être parfaitement lisible en taille réelle, mais devenir du bruit visuel à l’échelle d’une carte. Un seul titre clair sur un fond très contrasté reste lisible de manière fiable sur toutes les surfaces où l’image finit par apparaître.

twitter:card nécessite sa propre déclaration

Paramètre og:image ne suffit pas automatiquement pour un grand aperçu d’image sur X/Twitter. Le système de cartes Twitter lit sa propre twitter:card balise meta pour décider du style de carte ; sans elle, certains clients Twitter reviennent à une petite carte à miniature même si une parfaitement bonne og:image est présent.

Déclarez-le explicitement :

<meta name="twitter:card" content="summary_large_image" />

Twitter utilisera en secours og:image pour l’image réelle si twitter:image n’est pas défini séparément ; vous n’avez donc généralement pas besoin de dupliquer l’URL de l’image. Mais la déclaration du type de carte n’est pas facultative si vous voulez la présentation avec grande image.

Un diagnostic rapide dans l'ordre

1. Vérifiez l'URL absolue, non relative, et son ouverture directe.
2. Confirmez JPG ou PNG, pas WebP.
3. Confirmez des dimensions proches de 1200×630.
4. Confirmer twitter:card est défini si c’est précisément l’aperçu Twitter/X qui est incorrect.
5. Exécutez le débogueur de la plateforme pour forcer une nouvelle collecte avant de supposer que la correction n’a pas fonctionné.
6. Sans débogueur, changez la version dans la requête URL pour renouveler le cache.

Questions fréquentes