Taille image open graph : 1200 × 630 pour toutes les surfaces

La taille image open graph tient en une réponse qui convient à toutes les surfaces : 1200 × 630 pixels, JPG ou PNG, moins de 5 Mo. Ce seul fichier respecte les dimensions recommandées par Meta, reste au format 1.91:1 demandé, passe sous les deux plafonds de poids documentés et sert de repli à la carte X. Il ne faut pas un jeu d'images. Il faut une image et quatre lignes de balisage.

Avant cette page

Ce chapitre suppose que les quatre propriétés Open Graph obligatoires sont déjà présentes sur vos pages. Si vous n'en êtes pas sûr, le décompte sur 26 pages d'accueil réelles se trouve dans open graph tags on 26 homepages (en anglais), qui reprend aussi la liste officielle des propriétés obligatoires. Pour la balise voisine qui décrit la page dans les résultats, voyez comment rédiger une meta description.

Pourquoi un seul fichier suffit

Chaque surface qui affiche un aperçu lit les deux mêmes familles de balises, dans le même ordre, puis recadre le résultat dans son propre cadre. L'image que vous fournissez est une entrée pour la mise en page de quelqu'un d'autre. C'est pourquoi un seul fichier généreux vaut mieux qu'un dossier de variantes par plateforme : vous ne contrôlez pas le recadrage, donc vous contrôlez la source.

Le protocole Open Graph fait de og:image l'une de ses quatre propriétés obligatoires. Il définit aussi les propriétés structurées optionnelles : largeur, hauteur et description de l'image. Et si vous en fournissez plusieurs : « Si une balise peut avoir plusieurs valeurs, placez simplement plusieurs versions de la même balise meta sur la page. La première balise, de haut en bas, est privilégiée en cas de conflit » (ogp.me, consulté le 2026-10-27).

L'image est votre fichier. Le recadrage appartient à celui qui l'affiche. Dimensionnez pour le cadre que vous ne voyez pas.

Taille image open graph : les chiffres et leur source

Deux sources publiées fixent les contraintes, et elles ne se contredisent pas : la limite contraignante est simplement la plus stricte des deux. Le relevé de 26 pages d'accueil cité plus bas a été fait le 2026-08-27 et n'a pas été refait pour cette version.

Meta demande des images « d'au moins 1200 x 630 pixels pour un affichage optimal sur les écrans haute résolution », avec une dimension minimale de 200 x 200 et un ratio aussi proche que possible de 1.91:1 pour éviter le recadrage dans le fil. X précise de son côté que les images doivent peser moins de 5 Mo, que JPG, PNG, WEBP et GIF sont acceptés, que seule la première image d'un GIF animé est utilisée et que le SVG n'est pas pris en charge (documentation Meta et référence des cartes X, vérifiées le 2026-08-27).

L'intersection sûre est donc 1200 × 630, JPG ou PNG, sous 5 Mo. C'est le chiffre à transmettre à la personne qui fabrique le fichier.

Le balisage à coller

Quatre lignes font le travail obligatoire ; la cinquième et la sixième évitent un aller-retour et décrivent l'image. Uniquement des URL absolues : un chemin relatif à la racine est la cause la plus fréquente de panne.

<meta property="og:image" content="https://exemple.fr/og/accueil.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Une ligne qui décrit l'image">
<meta name="twitter:card" content="summary_large_image">

Attention aux attributs. Les valeurs Open Graph vont sur property, celles de la carte X sur name. Les deux familles sont largement lues dans un sens comme dans l'autre, et dans notre relevé du 2026-08-27 sur 26 pages d'accueil, trois sites écrivaient au moins l'une de ces balises sur le mauvais attribut, dont MDN qui place ses dix balises og: sur name.

Vérifier en trois commandes

Lancez ces commandes sur une URL en ligne. Chacune se termine par une valeur comparable au tableau ci-dessus.

1. Lire ce que la page déclare : curl -sL --compressed -A 'Mozilla/5.0' https://exemple.fr/ | grep -o '<meta[^>]*og:image[^>]*>'. Si rien ne sort, la balise est injectée par script et la plupart des lecteurs ne la verront jamais.
2. Vérifier que l'URL est absolue et joignable : copiez la valeur de contenu et lancez curl -sI <url> | head -3. Vous voulez un 200 et un type de contenu image. Un 404 ici donne aucune image et aucune erreur visible.
3. Vérifier que la taille réelle en pixels correspond à ce qui est déclaré. Sur macOS : sips -g pixelWidth -g pixelHeight fichier.jpg. Déclarer 1200 × 630 sur un fichier de 800 × 600 est pire que ne rien déclarer, car un lecteur peut réserver une place qu'il ne recevra jamais.

Trois façons de se tromper

Les trois se voient dans le balisage ou en une requête HTTP. Aucune n'exige un aperçu rendu pour être détectée.

1. Un chemin relatif dans og:image. Le protocole attend une URL. Dans le relevé du 2026-08-27 sur 26 pages d'accueil, un site déclarait og:image et twitter:image en /dev-cdn/v/marketing/…. Un lecteur qui ne résout pas par rapport à la page n'obtient rien, et votre navigateur ne vous montrera jamais le problème.
2. Un logo au lieu d'une bannière. Un fichier carré dans un cadre 1.91:1 est soit entouré de bandes, soit recadré au centre. Dans le même relevé, sur les sept sites qui déclaraient des dimensions, quatre annonçaient moins de 1200 × 630 : 400 × 400, 512 × 512, 800 × 600 et 1024 × 1024.
3. Du texte incrusté dans l'image. Ce que vous y écrivez sera recadré par des cadres que vous ne voyez pas, et reste invisible pour tout ce qui lit du texte. Mettez les mots dans og:title, où ils sont déjà lus.

Où cela s'arrête

Bien dimensionner ne rafraîchit pas l'aperçu. Chaque surface met en cache ce qu'elle a récupéré la première fois, et aucune ne relit selon votre calendrier. Si vous changez le fichier, changez aussi l'URL : un nouveau chemin est le seul mécanisme de contournement de cache qui fonctionne partout de la même façon.

La seconde limite est la mesure. Nous ne vérifions pas de rendu final sur chaque surface pour cette version. Le faire honnêtement supposerait de publier un vrai lien sur chacune, et les validateurs qui répondaient autrefois sont derrière une connexion. Tout ici vient des exigences publiées et de ce que 26 pages d'accueil déclarent réellement. Si une plateforme recadre votre image autrement que cette page ne le prévoit, la plateforme a raison et cette page est incomplète.

Questions fréquentes

Quelle est la bonne taille d'image Open Graph ?

1200 × 630 pixels, le minimum recommandé par Meta pour les écrans haute résolution et le ratio 1.91:1 demandé. Gardez le fichier sous 5 Mo pour respecter aussi la limite de X, et en JPG ou PNG pour passer toutes les listes de formats.

Faut-il une image séparée pour X ?

Non. La référence des cartes X documente og:image comme repli de twitter:image, donc un fichier couvre les deux. Ajoutez-en un second uniquement si les deux doivent vraiment différer, en sachant que vous aurez deux fichiers à synchroniser.

Pourquoi mon aperçu n'affiche aucune image ?

Par ordre de fréquence : l'URL est relative, elle ne renvoie pas 200, la balise est injectée par script et absente du HTML livré, ou le fichier est un SVG. X indique clairement que le SVG n'est pas pris en charge.

Faut-il déclarer og:image:width et og:image:height ?

Elles sont optionnelles et utiles, car un lecteur qui connaît les dimensions peut réserver la carte avant l'arrivée de l'image. Déclarez-les seulement si elles sont vraies. Dans notre relevé, seules sept des 26 pages d'accueil les déclaraient.

og:image:alt est-il important ?

C'est la description accessible de l'image de la carte, et presque personne ne l'écrit : trois pages sur 26 dans notre relevé. Cela coûte une ligne. Pour ce que ces mêmes pages envoient côté X, voir twitter card tags on 26 homepages (en anglais), et pour comprendre ce qu'un moteur reçoit de votre page avant toute analyse, voyez le registre de promotion QueryWin.