Générateur d'image de remplissage, gratuit

Comment ça marche

1. Définissez les dimensions : saisissez la largeur et la hauteur en pixels de votre image de remplissage.
2. Personnalisez l'apparence : choisissez la couleur de fond, la couleur du texte et le libellé à afficher (ou laissez vide pour afficher les dimensions).
3. Utilisez ou téléchargez : copiez l'URL de l'image pour un usage en HTML/CSS, ou téléchargez directement le PNG pour vos maquettes et designs.

Pourquoi utiliser le générateur d'images de remplissage ?

Pendant le développement web et la création de maquettes, on a souvent besoin d'images avant que le vrai contenu ne soit prêt. Les images de remplissage occupent l'espace des mises en page pour montrer les proportions, tester le comportement responsive et communiquer l'intention design aux clients. Plutôt que de chercher des photos de banque ou de créer des images vides à la main, cet outil génère instantanément des images correctement dimensionnées avec les dimensions et couleurs voulues.

Fonctionnalités

• Dimensions personnalisées : n'importe quelle largeur et hauteur en pixels, formats carré, portrait, paysage ou bannière.
• Personnalisation des couleurs : définissez la couleur de fond et du texte via codes hex ou sélecteurs de couleur.
• Texte de libellé personnalisé : affichez n'importe quel texte sur l'image, ou laissez par défaut le libellé des dimensions (par ex. 400×300).
• URL instantanée : obtenez un URI de données à coller directement dans les attributs src pour tester.
• Téléchargement PNG : téléchargez l'image de remplissage en fichier PNG pour l'utiliser dans vos outils de design.

Questions fréquentes

Puis-je l'utiliser dans des attributs src HTML ?

Oui. L'image générée est disponible sous forme d'URI de données que vous pouvez coller directement dans un attribut <img src=""> de votre HTML. Aucun hébergement ni URL externe n'est nécessaire.

Quelles tailles sont courantes pour les images de remplissage ?

Tailles courantes : images principales (1200×630), vignettes d'articles (400×300), avatars (100×100), images Open Graph (1200×628) et bannières publicitaires (728×90). Saisissez n'importe quelle taille personnalisée selon vos besoins.

Comment utiliser les images de remplissage en CSS ?

Copiez l'URI de données et utilisez-le en arrière-plan CSS : background-image: url("data:image/png;base64,…"). Cela fonctionne dans tous les navigateurs modernes et ne nécessite aucun fichier externe.

Brève histoire des services d'images de remplacement

Les services d'images de remplacement sont apparus en 2010 lorsque les designers web avaient besoin d'un moyen rapide de remplir des maquettes avant l'arrivée des assets finaux. placehold.it, lancé par Dave Reilly en 2010, fut le premier service largement utilisé : collez une URL comme placehold.it/300x200 dans une balise <img> et obtenez un rectangle gris. placekitten.com a suivi la même année, remplaçant les rectangles par des chatons aléatoires, et dummyimage.com (Russell Heimlich, 2010) a ajouté la personnalisation des couleurs. Les variantes fantaisistes ont proliféré : fillmurray.com (photos de Bill Murray, 2013), placebeard.it (barbes, 2014), placecage.com (Nicolas Cage). Les successeurs sérieux sont arrivés plus tard : Lorem Pixel (disparu vers 2017) et Lorem Picsum de David Marby (2018), qui sert des photos aléatoires d'Unsplash à toute taille. Vers 2014, Facebook a popularisé le motif «skeleton screen» : afficher des formes grises là où le contenu va se charger. En 2019, Wolt a publié BlurHash, une chaîne de 20 octets qui se décode en un placeholder flou basse résolution de la vraie image. Aujourd'hui, ThumbHash (Evan Wallace, 2023) et la propriété CSS native aspect-ratio (Chrome 88, janvier 2021) permettent de réserver l'espace de l'image sans aucun service externe.

Tailles d'image standard à mémoriser

• Open Graph (1200×630). La taille canonique pour les aperçus de liens définie par le protocole Open Graph de Facebook. LinkedIn, Slack, Discord, Twitter (sans Twitter Card) y reviennent tous par défaut. Ratio 1,91:1.
• Twitter Card summary_large_image (1200×675). Ratio 16:9 pour les aperçus dans le fil. Le 1200×628 que vous voyez cité est l'ancien standard, remplacé par 1200×675 en 2023.
• Instagram (1080×1080 carré, 1080×1350 portrait, 1080×1920 story). Tout ce qui dépasse 1080 de large est sous-échantillonné. Ratio des stories : 9:16.
• Miniature YouTube (1280×720). 16:9. YouTube génère automatiquement ces images à partir des frames vidéo ; les miniatures personnalisées doivent peser moins de 2 Mo.
• Tailles publicitaires IAB. L'Interactive Advertising Bureau a standardisé les dimensions des bannières : 728×90 (leaderboard), 300×250 (rectangle moyen, la taille la plus achetée au monde), 300×600 (demi-page), 160×600 (gratte-ciel large), 320×50 et 320×100 (mobile).
• Favicons. 16×16 et 32×32 pour les onglets de navigateur, 180×180 pour les icônes Apple touch, 192×192 et 512×512 pour manifest.json Android, 512×512 minimum pour les invites d'installation PWA.
• En-têtes d'email (600×200). La plupart des clients email plafonnent la largeur rendue à 600 px. Aller au-delà se fait écraser ou des barres de défilement apparaissent dans Outlook desktop.

Placeholders et Core Web Vitals

Les Core Web Vitals de Google (lancés en mai 2020) mesurent l'expérience utilisateur et alimentent le classement de recherche. Deux des trois métriques dépendent directement de la façon dont vous gérez les images. CLS (Cumulative Layout Shift) pénalise le contenu qui saute pendant le chargement. La cause la plus commune : une balise <img> sans attributs explicites width et height, ce qui donne au navigateur zéro espace à réserver jusqu'à ce que l'image finisse de télécharger. Un score supérieur à 0,1 échoue à la métrique. Le correctif est trivial : toujours définir width et height, même sur les images responsive, pour que le navigateur puisse calculer le ratio d'aspect. LCP (Largest Contentful Paint) mesure quand le plus grand élément visible se charge. Pour la plupart des pages, cet élément est l'image hero. Tout ce qui dépasse 2,5 secondes échoue. Stratégies : servir des formats modernes (WebP, AVIF), utiliser loading="lazy" sur les images sous la ligne de flottaison (Chrome 76, août 2019), et utiliser fetchpriority="high" sur le hero. Les placeholders comblent le vide visuellement : skeleton screens pour la mise en page, BlurHash ou ThumbHash pour un aperçu instantané de la palette de couleurs de l'image réelle.

Guide de décision des formats d'image

• PNG (1996). Sans perte, supporte la transparence, sans problèmes de brevets. Idéal pour les logos, icônes, captures d'écran, graphiques avec arêtes nettes. Le PNG-8 à couleurs indexées (256 couleurs) est radicalement plus petit que le PNG-24 RVB et souvent invisible pour les icônes UI.
• JPEG (1992). Avec perte, sans transparence, optimisé pour les photographies. Qualité 75-85 est le sweet spot pour le web ; visuellement indistinguible de la qualité 95 à la moitié de la taille. Évitez JPEG pour tout ce qui a des arêtes nettes (texte, logos) : vous obtenez des artefacts de ringing visibles.
• WebP (Google, 2010). 25-35 % plus petit que JPEG à qualité visuelle équivalente, également plus petit que PNG en sans perte. Supporte la transparence, l'animation, les modes avec et sans perte. Support navigateur : 97 % en 2024. Choix par défaut pour les nouveaux sites.
• AVIF (Alliance for Open Media, 2019). Basé sur le codec vidéo AV1. Environ 50 % plus petit que JPEG, 20 % plus petit que WebP. Coût CPU plus élevé à l'encodage. Support navigateur : ~93 % en 2024, manquant sur les anciens Safari. Utilisez derrière un fallback <picture>.
• SVG. Vectoriel. Mise à l'échelle infinie sans perte de qualité. Un logo en SVG fait souvent 500 octets contre 10 Ko en PNG 512×512. Le SVG inline en HTML évite complètement une requête HTTP supplémentaire. Ne pas utiliser pour les photographies.
• Data URI. data:image/png;base64,... intègre les octets de l'image directement dans le HTML ou le CSS. Économise une requête HTTP au prix d'une inflation du fichier environnant d'environ 33 % (surcoût base64). Vaut le coup pour les minuscules vignettes placeholder, jamais pour les images hero.

Où les images de remplacement sont vraiment utilisées

• Wireframes et maquettes. Figma, Sketch, Adobe XD, Penpot supportent tous le glisser-déposer d'images placeholder. Les designers esquissent les mises en page avant que la direction artistique n'arrive, utilisant des rectangles gris ou le texte de dimension comme placeholders visuels.
• Skeleton screens. Twitter, Facebook, YouTube, LinkedIn affichent tous des placeholders en blocs gris pendant que le contenu se charge. Les recherches de Luke Wroblewski (2013) montrent que les skeleton screens font ressentir le temps de chargement jusqu'à 20 % plus rapide que les spinners.
• Histoires de design system. Storybook, Histoire et Ladle rendent des aperçus de composants qui ont besoin d'images de remplacement. Un ensemble de placeholders cohérent rend les captures d'écran reproductibles entre les builds CI.
• Maquettes d'email. Litmus, Email on Acid, les constructeurs de templates Mailchimp. Les clients email varient énormément dans le support des images (Outlook desktop, Gmail web, iOS Mail), donc les designers testent avec des placeholders avant d'échanger contre les assets de production.
• Épreuves d'impression. Les mises en page de livres, les pages de magazines et les designs d'emballage utilisent des placeholders FPO («for position only») pendant la composition. Les dimensions vivent dans la mise en page bien avant que le photographe livre.
• Tutoriels et documentation. Quand vous écrivez «comment construire un composant card», vous avez besoin d'images de remplacement qui ne casseront pas si la source change. Les placeholders auto-hébergés survivent quand les services externes ferment (comme Lorem Pixel l'a fait).
• Tests A/B et prototypes. Tester rapidement des mises en page avec trois tailles d'image différentes est plus rapide avec des placeholders générés qu'en re-rendant les vrais assets.

Erreurs qui nuisent à la performance des pages

• Oublier les attributs width et height. La cause la plus commune de mauvais scores CLS. Même avec des images responsive pilotées par CSS, définissez les width et height intrinsèques pour que le navigateur réserve le bon ratio d'aspect. Les navigateurs modernes calculent aspect-ratio: width/height automatiquement à partir de ces attributs depuis 2020.
• Servir des placeholders 4096×4096 pour des affichages 200×200. Vingt fois les octets pour aucun bénéfice visuel. Faites correspondre les dimensions du placeholder à la taille rendue réelle, ou utilisez srcset avec plusieurs variantes.
• Texte alt vide ou manquant. Les lecteurs d'écran annoncent «image» sans contexte. Pour les placeholders purement décoratifs, utilisez alt="" explicitement pour signaler «passe ça». Pour les images de contenu, écrivez la description même sur les placeholders pour que la QA détecte le copy manquant.
• Intégrer d'énormes data URIs. Une image de 100 Ko en base64 devient ~133 Ko à l'intérieur de votre HTML, bloque le parsing et ruine la mise en cache (le HTML n'est généralement pas mis en cache agressivement, les images si). Utilisez les data URIs uniquement sous ~2-4 Ko.
• Dépendre de placehold.it / lorempixel / services externes en production. Ils tombent. Lorem Pixel a disparu vers 2017 et a cassé des milliers de sites de démo. Pour les tutoriels, démos et histoires, générez les placeholders vous-même ou auto-hébergez-les.
• PNG pour les photographies, JPEG pour les logos. Une photo en PNG est 3 à 5 fois plus grosse que la même image en JPEG. Un logo en JPEG obtient des anneaux de compression laids autour des arêtes. Choisissez le format selon le type de contenu, pas par habitude.
• Sauter loading="lazy". Les images sous la ligne de flottaison qui se chargent avidement entrent en concurrence pour la bande passante avec le hero. Ajoutez loading="lazy" à tout ce qui est sous le viewport. Natif, aucune bibliothèque nécessaire, supporté depuis Chrome 76 (août 2019) et Safari 15.4 (2022).

Autres questions fréquentes

Pourquoi l'étiquette de dimension est-elle si utile sur un placeholder ?

Quand vous avez une douzaine de placeholders dans une mise en page à différentes tailles, l'étiquette vous dit immédiatement quel slot est lequel. «400×300» sur un rectangle gris est plus informatif que de deviner si une card est 4:3 ou 16:9. Designers et développeurs revoyant une maquette peuvent repérer les éléments mal dimensionnés de l'autre bout de la pièce.

Quelle est la différence entre BlurHash, ThumbHash et LQIP ?

Les trois encodent un minuscule aperçu d'une image qui se décode en placeholder flou. LQIP («low-quality image placeholder») est juste un petit JPEG (~100 octets à 2 Ko). BlurHash (Wolt, 2019) encode toute image en une chaîne ASCII de 20-30 caractères que vous stockez dans votre base de données ; le temps de décodage est en microsecondes. ThumbHash (Evan Wallace, 2023) est similaire mais 30-50 % plus petit pour la même qualité, et rend les arêtes plus nettes. Les frameworks modernes (Next.js, Astro, Hugo) supportent tous BlurHash nativement.

Dois-je utiliser SVG ou PNG pour les vignettes placeholder ?

SVG si le placeholder est une forme simple (rectangle, icône, motif géométrique). Un SVG inline de 50 octets bat un PNG de 2 Ko à chaque fois. PNG si vous avez besoin d'un rendu de texte précis au pixel ou de fallbacks de police spécifiques : le rendu de texte SVG varie entre navigateurs et plateformes. Pour les placeholders dynamiques générés côté client, cet outil produit des PNG car le rendu de texte canvas est prévisible entre navigateurs.

Le PNG généré inclut-il des EXIF ou des métadonnées cachées ?

Non. Les PNG générés par les API canvas HTML toBlob() ou toDataURL() contiennent uniquement les chunks IHDR, IDAT et IEND plus un chunk tEXt minimal sur certains navigateurs. Pas de GPS, pas d'infos appareil, pas d'historique d'édition, pas d'identifiant utilisateur. Comparez avec les JPEG de caméra téléphone qui fuitent les coordonnées GPS et les numéros de série de l'appareil.

Quelque chose est-il envoyé à un serveur quand je génère une image ici ?

Non. L'image est dessinée localement via l'API Canvas 2D HTML5 dans votre navigateur. Ouvrez l'onglet Network dans DevTools pendant la génération : zéro requête sortante pour l'image. Sûr pour les maquettes confidentielles, NDA, travail client et designs de produits non publiés.