Platzhalterbild-Generator

So funktioniert es

1. Maße festlegen: Geben Sie Breite und Höhe in Pixeln für Ihr Platzhalterbild ein.
2. Aussehen anpassen: Wählen Sie Hintergrundfarbe, Textfarbe und den anzuzeigenden Beschriftungstext (oder lassen Sie es leer für die Maßangabe).
3. Verwenden oder herunterladen: Kopieren Sie die Bild-URL für die Nutzung in HTML/CSS oder laden Sie das PNG direkt für Mockups und Designs herunter.

Warum den Platzhalterbild-Generator nutzen?

Während der Webentwicklung und beim Erstellen von Designmockups brauchen Sie oft Bilder, bevor der echte Inhalt fertig ist. Platzhalterbilder füllen Layouts, um Proportionen zu zeigen, responsives Verhalten zu testen und die Designabsicht an Kundinnen und Kunden zu kommunizieren. Statt Stockfotos zu suchen oder leere Bilder von Hand zu erstellen, erzeugt dieses Tool sofort korrekt dimensionierte Platzhalter mit den von Ihnen gewählten Maßen und Farben.

Funktionen

• Individuelle Maße: Beliebige Breite und Höhe in Pixeln, quadratisch, hochkant, querformat oder Banner.
• Farbanpassung: Hintergrund- und Textfarbe per Hex-Code oder Farbwähler festlegen.
• Eigener Beschriftungstext: Beliebigen Text auf dem Bild anzeigen oder die Maße als Standardbeschriftung verwenden (z. B. 400×300).
• Sofort-URL: Erhalten Sie eine Daten-URI, die direkt in src-Attribute eingefügt werden kann zum Testen.
• PNG-Download: Laden Sie den erzeugten Platzhalter als PNG-Datei zur Nutzung in Designwerkzeugen herunter.

Häufige Fragen

Kann ich das in HTML-src-Attributen nutzen?

Ja. Das erzeugte Bild liegt als Daten-URI vor, die Sie direkt in ein <img src="">-Attribut Ihres HTMLs einfügen können. Kein Hosting und keine externe URL erforderlich.

Welche Größen sind für Platzhalterbilder gängig?

Gängige Größen sind: Heldenbilder (1200×630), Blog-Vorschaubilder (400×300), Avatare (100×100), Open-Graph-Bilder (1200×628) und Bannerwerbungen (728×90). Geben Sie eine beliebige Größe für Ihre spezifischen Layout-Anforderungen ein.

Wie verwende ich Platzhalterbilder in CSS?

Kopieren Sie die Daten-URI und nutzen Sie sie als CSS-Hintergrund: background-image: url("data:image/png;base64,…"). Das funktioniert in allen modernen Browsern und benötigt keine externen Dateien.

Eine kurze Geschichte der Platzhalterbilddienste

Platzhalterbilddienste entstanden im Jahr 2010, als Webdesigner eine schnelle Möglichkeit brauchten, Mockups zu füllen, bevor die finalen Assets eintrafen. placehold.it, 2010 von Dave Reilly gestartet, war der erste weit verbreitete Dienst: Eine URL wie placehold.it/300x200 in einen beliebigen <img>-Tag einfügen und ein graues Rechteck erhalten. placekitten.com folgte im selben Jahr und ersetzte Rechtecke durch zufällige Kätzchen, und dummyimage.com (Russell Heimlich, 2010) fügte Farbanpassung hinzu. Skurrile Varianten vermehrten sich: fillmurray.com (Bill-Murray-Fotos, 2013), placebeard.it (Bärte, 2014), placecage.com (Nicolas Cage). Die ernsthaften Nachfolger kamen später: Lorem Pixel (um 2017 eingestellt) und Lorem Picsum von David Marby (2018), das zufällige Fotos von Unsplash in beliebiger Größe liefert. Um 2014 popularisierte Facebook das «Skeleton-Screen»-Muster: graue Formen dort zeigen, wo Inhalte laden werden. Bis 2019 veröffentlichte Wolt BlurHash, eine 20-Byte-Zeichenkette, die zu einem niedrig aufgelösten unscharfen Platzhalter des echten Bildes dekodiert. Heute ermöglichen ThumbHash (Evan Wallace, 2023) und die native CSS-Eigenschaft aspect-ratio (Chrome 88, Januar 2021), Bildraum ganz ohne externe Dienste zu reservieren.

Standardbildgrößen, die man sich merken sollte

• Open Graph (1200×630). Die kanonische Link-Vorschau-Größe, definiert durch Facebooks Open-Graph-Protokoll. LinkedIn, Slack, Discord, Twitter (wenn keine Twitter Card gesetzt ist) greifen alle darauf zurück. Seitenverhältnis 1,91:1.
• Twitter Card summary_large_image (1200×675). 16:9-Verhältnis für Feed-Vorschauen. Das 1200×628, das oft zitiert wird, ist der alte Standard, ersetzt durch 1200×675 im Jahr 2023.
• Instagram (1080×1080 quadratisch, 1080×1350 hochkant, 1080×1920 Story). Alles über 1080 Breite wird heruntergerechnet. Story-Seitenverhältnis ist 9:16.
• YouTube-Thumbnail (1280×720). 16:9. YouTube generiert diese automatisch aus Videoframes; hochgeladene benutzerdefinierte Thumbnails müssen unter 2 MB sein.
• IAB-Anzeigengrößen. Das Interactive Advertising Bureau hat Bannerdimensionen standardisiert: 728×90 (Leaderboard), 300×250 (mittleres Rechteck, die weltweit meistgekaufte Größe), 300×600 (Halbseite), 160×600 (breiter Skyscraper), 320×50 und 320×100 (mobil).
• Favicons. 16×16 und 32×32 für Browser-Tabs, 180×180 für Apple-Touch-Icons, 192×192 und 512×512 für Android-manifest.json, 512×512 Minimum für PWA-Installationsaufforderungen.
• E-Mail-Header (600×200). Die meisten E-Mail-Clients begrenzen die gerenderte Breite auf 600 px. Breiter wird gestaucht oder Scrollbalken erscheinen in Outlook-Desktop.

Platzhalter und Core Web Vitals

Googles Core Web Vitals (eingeführt im Mai 2020) messen die Nutzererfahrung und fließen in das Suchranking ein. Zwei der drei Metriken hängen direkt davon ab, wie Sie Bilder behandeln. CLS (Cumulative Layout Shift) bestraft Inhalte, die beim Laden der Seite springen. Die häufigste Ursache: ein <img> ohne explizite width- und height-Attribute, was dem Browser null Platz zum Reservieren gibt, bis das Bild fertig heruntergeladen ist. Ein Wert über 0,1 verfehlt die Metrik. Die Lösung ist trivial: Setzen Sie immer Breite und Höhe, auch bei responsiven Bildern, damit der Browser das Seitenverhältnis berechnen kann. LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element lädt. Bei den meisten Seiten ist dieses Element das Hero-Bild. Alles über 2,5 Sekunden verfehlt. Strategien: moderne Formate (WebP, AVIF) ausliefern, loading="lazy" auf Bildern unterhalb der Falz verwenden (Chrome 76, August 2019), und fetchpriority="high" auf dem Hero. Platzhalter überbrücken die Lücke visuell: Skeleton-Screens für das Layout, BlurHash oder ThumbHash für eine sofortige Vorschau der tatsächlichen Bildfarbpalette.

Entscheidungsleitfaden für Bildformate

• PNG (1996). Verlustfrei, unterstützt Transparenz, keine Patentprobleme. Am besten für Logos, Icons, Screenshots, Grafiken mit scharfen Kanten. Indexfarben-PNG-8 (256 Farben) ist dramatisch kleiner als RGB-PNG-24 und oft unsichtbar für UI-Icons.
• JPEG (1992). Verlustbehaftet, keine Transparenz, optimiert für Fotografien. Qualität 75-85 ist der Sweet Spot für das Web; visuell ununterscheidbar von Qualität 95 bei halber Größe. Vermeiden Sie JPEG für alles mit scharfen Kanten (Text, Logos): Sie erhalten sichtbare Ringing-Artefakte.
• WebP (Google, 2010). 25-35 % kleiner als JPEG bei gleicher visueller Qualität, auch kleiner als PNG bei verlustfreier Kompression. Unterstützt Transparenz, Animation, sowohl verlustbehaftete als auch verlustfreie Modi. Browser-Unterstützung: 97 % Stand 2024. Standardwahl für neue Sites.
• AVIF (Alliance for Open Media, 2019). Basiert auf dem AV1-Video-Codec. Etwa 50 % kleiner als JPEG, 20 % kleiner als WebP. Höhere CPU-Kosten beim Encoden. Browser-Unterstützung: ~93 % Stand 2024, fehlt bei älteren Safari. Verwenden Sie hinter einem <picture>-Fallback.
• SVG. Vektor. Skaliert unendlich ohne Qualitätsverlust. Ein Logo als SVG ist oft 500 Byte gegenüber 10 KB als 512×512-PNG. Inline-SVG in HTML vermeidet eine zusätzliche HTTP-Anfrage vollständig. Nicht für Fotografien verwenden.
• Data URI. data:image/png;base64,... bettet die Bildbytes direkt in HTML oder CSS ein. Spart eine HTTP-Anfrage zum Preis einer Aufblähung der umgebenden Datei um ~33 % (Base64-Overhead). Lohnt sich für winzige Platzhalter-Thumbnails, nie für Hero-Bilder.

Wo Platzhalterbilder tatsächlich verwendet werden

• Wireframes und Mockups. Figma, Sketch, Adobe XD, Penpot unterstützen alle Drag-and-Drop-Platzhalterbilder. Designer skizzieren Layouts, bevor die Art Direction eintrifft, und verwenden graue Rechtecke oder den Dimensionstext als visuelle Platzhalter.
• Skeleton-Screens. Twitter, Facebook, YouTube, LinkedIn zeigen alle graue Blockplatzhalter, während Inhalte laden. Forschung von Luke Wroblewski (2013) zeigt, dass Skeleton-Screens die wahrgenommene Ladezeit bis zu 20 % schneller wirken lassen als Spinner.
• Design-System-Stories. Storybook, Histoire und Ladle rendern Komponenten-Previews, die Ersatzbilder benötigen. Ein konsistentes Platzhalter-Set macht Screenshots zwischen CI-Builds reproduzierbar.
• E-Mail-Mockups. Litmus, Email on Acid, Mailchimp-Template-Builder. E-Mail-Clients variieren stark in der Bildunterstützung (Outlook-Desktop, Gmail-Web, iOS Mail), daher testen Designer mit Platzhaltern, bevor sie auf Produktions-Assets wechseln.
• Druckproofs. Buchlayouts, Magazinseiten und Verpackungsdesigns verwenden FPO-Platzhalter («for position only») während des Satzes. Die Dimensionen leben lange im Layout, bevor der Fotograf liefert.
• Tutorials und Dokumentation. Beim Schreiben von «Wie man eine Card-Komponente baut» braucht man Ersatzbilder, die nicht kaputtgehen, wenn sich die Quelle ändert. Selbst gehostete Platzhalter überleben, wenn externe Dienste schließen (wie Lorem Pixel es tat).
• A/B-Tests und Prototypen. Layouts mit drei verschiedenen Bildgrößen schnell zu testen ist mit generierten Platzhaltern schneller als mit dem erneuten Rendern echter Assets.

Fehler, die der Seitenleistung schaden

• Vergessen der width- und height-Attribute. Die häufigste Ursache schlechter CLS-Werte. Selbst bei CSS-gesteuerten responsiven Bildern setzen Sie die intrinsischen width und height, damit der Browser das richtige Seitenverhältnis reserviert. Moderne Browser berechnen aspect-ratio: width/height seit 2020 automatisch aus diesen Attributen.
• 4096×4096-Platzhalter für 200×200-Anzeigen ausliefern. Zwanzigfache Bytes ohne visuellen Nutzen. Passen Sie Platzhalterdimensionen an die tatsächlich gerenderte Größe an oder verwenden Sie srcset mit mehreren Varianten.
• Leerer oder fehlender Alt-Text. Screenreader kündigen «Bild» ohne Kontext an. Für rein dekorative Platzhalter verwenden Sie alt="" explizit, um «überspringen» zu signalisieren. Für Inhaltsbilder schreiben Sie die Beschreibung auch auf Platzhalter, damit die QA fehlende Copy entdeckt.
• Riesige Data URIs inlinen. Ein 100 KB großes Bild als Base64 wird zu ~133 KB in Ihrem HTML, blockiert das Parsing und ruiniert das Caching (HTML wird normalerweise nicht aggressiv gecached, Bilder schon). Verwenden Sie Data URIs nur unter ~2-4 KB.
• Abhängigkeit von placehold.it / lorempixel / externen Diensten in der Produktion. Sie fallen aus. Lorem Pixel verschwand um 2017 und brach Tausende von Demo-Sites. Für Tutorials, Demos und Stories generieren Sie Platzhalter selbst oder hosten Sie sie selbst.
• PNG für Fotografien, JPEG für Logos. Ein Foto als PNG ist 3- bis 5-mal größer als dasselbe Bild als JPEG. Ein Logo als JPEG bekommt hässliche Kompressionsringe um die Kanten. Wählen Sie das Format nach Inhaltstyp, nicht nach Gewohnheit.
• Überspringen von loading="lazy". Bilder unterhalb der Falz, die eifrig laden, konkurrieren mit dem Hero um Bandbreite. Fügen Sie loading="lazy" zu allem unterhalb des Viewports hinzu. Nativ, keine Bibliothek erforderlich, unterstützt seit Chrome 76 (August 2019) und Safari 15.4 (2022).

Weitere häufig gestellte Fragen

Warum ist das Dimensionslabel auf einem Platzhalter so nützlich?

Wenn Sie ein Dutzend Platzhalter in einem Layout mit verschiedenen Größen haben, sagt Ihnen das Label sofort, welcher Slot welcher ist. «400×300» auf einem grauen Rechteck ist informativer, als zu raten, ob eine Card 4:3 oder 16:9 ist. Designer und Entwickler, die ein Mockup überprüfen, können fehl bemessene Elemente vom anderen Ende des Raums erkennen.

Was ist der Unterschied zwischen BlurHash, ThumbHash und LQIP?

Alle drei kodieren eine winzige Vorschau eines Bildes, das zu einem unscharfen Platzhalter dekodiert. LQIP («low-quality image placeholder») ist nur ein kleines JPEG (~100 Byte bis 2 KB). BlurHash (Wolt, 2019) kodiert jedes Bild in eine 20-30 Zeichen lange ASCII-Zeichenkette, die Sie in Ihrer Datenbank speichern; Dekodierzeit ist Mikrosekunden. ThumbHash (Evan Wallace, 2023) ist ähnlich, aber 30-50 % kleiner bei gleicher Qualität und rendert schärfere Kanten. Moderne Frameworks (Next.js, Astro, Hugo) unterstützen alle BlurHash standardmäßig.

Sollte ich SVG oder PNG für Platzhalter-Thumbnails verwenden?

SVG, wenn der Platzhalter eine einfache Form ist (Rechteck, Icon, geometrisches Muster). Ein 50-Byte-Inline-SVG schlägt jedes Mal ein 2 KB-PNG. PNG, wenn Sie pixelgenaues Text-Rendering oder spezifische Schriftart-Fallbacks benötigen: Das SVG-Text-Rendering variiert zwischen Browsern und Plattformen. Für dynamische, clientseitig generierte Platzhalter produziert dieses Tool PNGs, weil das Canvas-Text-Rendering zwischen Browsern vorhersagbar ist.

Enthält das generierte PNG EXIF- oder versteckte Metadaten?

Nein. PNGs, die von den HTML-Canvas-APIs toBlob() oder toDataURL() generiert werden, enthalten nur die IHDR-, IDAT- und IEND-Chunks plus einen minimalen tEXt-Chunk in einigen Browsern. Kein GPS, keine Kamerainfo, keine Bearbeitungshistorie, kein Benutzerkennzeichen. Vergleichen Sie mit Telefonkamera-JPEGs, die GPS-Koordinaten und Geräteseriennummern preisgeben.

Wird etwas an einen Server gesendet, wenn ich hier ein Bild generiere?

Nein. Das Bild wird lokal über die HTML5-Canvas-2D-API in Ihrem Browser gezeichnet. Öffnen Sie den Network-Tab in DevTools während des Generierens: null ausgehende Anfragen für das Bild. Sicher für vertrauliche Mockups, NDAs, Kundenarbeit und unveröffentlichte Produktdesigns.