<object>

• Block-Element: Nimmt die volle verfügbare Breite ein und erzeugt einen eigenen Absatz
• Die URL der Ressource wird über das data-Attribut angegeben (nicht src!)
• Das type-Attribut gibt den MIME-Typ der Ressource an (z.B. application/pdf)
• Fallback-Content: Alles zwischen <object> und </object> wird angezeigt, wenn die Ressource nicht geladen werden kann. Das können Texte, Bilder oder sogar ein weiteres <object> sein
• Verschachtelte object-Elemente: Du kannst mehrere <object> ineinander verschachteln und so eine Fallback-Kette bauen: Der Browser versucht das äußere zuerst, dann das nächste, und zeigt am Ende den innersten Fallback
• <param>-Kind-Elemente: Mit <param> konntest du früher Parameter an Plugins übergeben (z.B. Flash-Variablen), heute kaum noch relevant
• Vergleich mit <embed>: <embed> ist ein Void-Element ohne schließenden Tag und hat deshalb keinen nativen Fallback-Mechanismus
• Vergleich mit <iframe>: <iframe> bietet mehr Kontrolle über Sicherheit (sandbox, allow), eigenen Browsing-Kontext und ist heute für die meisten Einbettungs-Szenarien die bessere Wahl

<object data="dokument.pdf" type="application/pdf" width="600" height="400">
  <p>Dein Browser kann kein PDF anzeigen. <a href="dokument.pdf">PDF herunterladen</a></p>
</object>

Das <object> Element hat ein öffnendes und ein schließendes Tag. Der Inhalt dazwischen ist der Fallback-Content, der nur sichtbar wird, wenn der Browser die Ressource im data-Attribut nicht darstellen kann. Die Angabe des type-Attributs ist optional, aber empfohlen: Ohne type muss der Browser den MIME-Typ selbst erraten, was zu Verzögerungen oder Fehlern führen kann.

Der Fallback-Content ist der größte Barrierefreiheits-Vorteil von <object> gegenüber <embed>. Screenreader können den Fallback-Text vorlesen, wenn die eingebettete Ressource nicht zugänglich ist. Trotzdem gibt es einiges zu beachten:

• Der Fallback-Content sollte den eingebetteten Inhalt beschreiben: nicht einfach nur “Inhalt konnte nicht geladen werden”, sondern eine sinnvolle Alternative bieten
• Ergänze das <object> Element mit einem aria-label, um Screenreadern eine kurze Beschreibung zu geben
• Für PDFs: Biete immer einen direkten Download-Link als Fallback an, damit alle Nutzer Zugang zum Inhalt haben
• Eingebettete Inhalte (PDFs, Flash, etc.) sind für Screenreader oft schwer zugänglich. Der Fallback ist in vielen Fällen die einzige barrierefreie Alternative

<object
  data="bericht.pdf"
  type="application/pdf"
  width="100%"
  height="600"
  aria-label="Quartalsbericht Q4 2025 als PDF"
>
  <p>
    Der Quartalsbericht kann nicht im Browser angezeigt werden.
    <a href="bericht.pdf">Bericht als PDF herunterladen (1,2 MB)</a>
  </p>
</object>

src statt data verwenden

<!-- Falsch: src funktioniert bei object nicht! -->
<object src="dokument.pdf" type="application/pdf" width="600" height="400">
  <p>Fallback</p>
</object>

<!-- Richtig: data ist das korrekte Attribut -->
<object data="dokument.pdf" type="application/pdf" width="600" height="400">
  <p>Fallback</p>
</object>

Das ist der häufigste Fehler mit <object>. Anders als bei <embed>, <img>, <script> und fast allen anderen HTML-Elementen heißt das URL-Attribut hier data, nicht src. Wenn du src verwendest, passiert einfach gar nichts: Der Browser ignoriert es still und zeigt den Fallback.

Kein Fallback-Content angegeben

<!-- Schlecht: Kein Fallback -->
<object data="praesentation.pdf" type="application/pdf" width="800" height="600">
</object>

<!-- Besser: Mit sinnvollem Fallback -->
<object data="praesentation.pdf" type="application/pdf" width="800" height="600">
  <p>Die Präsentation kann nicht angezeigt werden. <a href="praesentation.pdf">PDF herunterladen</a></p>
</object>

Der ganze Sinn von <object> gegenüber <embed> ist der Fallback-Content. Wenn du keinen Fallback angibst, verschenkst du den Hauptvorteil des Elements. Der Nutzer sieht dann einfach nichts, wenn sein Browser die Ressource nicht darstellen kann.

type-Attribut vergessen

<!-- Nicht ideal: Browser muss MIME-Typ raten -->
<object data="grafik.svg" width="400" height="300">
  <p>Fallback</p>
</object>

<!-- Besser: MIME-Typ explizit angeben -->
<object data="grafik.svg" type="image/svg+xml" width="400" height="300">
  <p>Fallback</p>
</object>

Ohne type-Attribut muss der Browser den MIME-Typ der Ressource selbst herausfinden. Das kann zu Verzögerungen führen (der Browser muss erst die Datei anfragen und den Content-Type-Header prüfen) oder sogar dazu, dass die Ressource falsch interpretiert wird. Gib den type immer explizit an.

Das <object> Element wird von allen modernen Browsern vollständig unterstützt. Die tatsächliche Darstellung hängt aber vom eingebetteten Inhaltstyp und den verfügbaren Plugins ab.

• Chrome

  Komplett

  Integrierter PDF-Viewer

• Firefox

  Komplett

  Integrierter PDF-Viewer

• Safari

  Komplett

  Integrierter PDF-Viewer

• Edge

  Komplett

  Integrierter PDF-Viewer

• Opera

  Komplett

  Integrierter PDF-Viewer

Beachte: Die Browser-Unterstützung für das Element selbst ist vollständig. Ob ein bestimmter Inhaltstyp (z.B. PDF, SVG) tatsächlich inline dargestellt wird, hängt vom jeweiligen Browser und dessen integrierten Viewern ab. Mobile Browser haben oft keinen integrierten PDF-Viewer und zeigen dann den Fallback-Content an. Genau das ist der Grund, warum du immer einen guten Fallback bereitstellen solltest.

Das <object> Element wird in HTML-Emails von keinem gängigen Email-Client unterstützt und sollte niemals in Emails verwendet werden.

• Gmail

  Keine

  Wird komplett entfernt

• Outlook

  Keine

  Wird komplett entfernt

• Apple Mail

  Keine

  Wird komplett entfernt

• Thunderbird

  Keine

  Wird komplett entfernt

• Yahoo Mail

  Keine

  Wird komplett entfernt

Aus Sicherheitsgründen entfernen alle Email-Clients <object> Elemente vollständig aus dem HTML. Das gilt auch für den Fallback-Content zwischen den Tags: Der wird ebenfalls nicht angezeigt. Verwende in Emails stattdessen direkte Links zu Dokumenten oder eingebettete Bilder mit <img>.