Embed vs object vs iframe

Embed vs object vs iframe

HTML offre tre elementi per includere contenuti esterni nella pagina: <embed>, <object> e <iframe>. Ognuno ha origini, use case e capacità diverse. Capirne le differenze ti aiuta a scegliere lo strumento giusto per PDF, video, contenuti Flash legacy o pagine HTML esterne. Vediamo quando e come usare ciascuno.

Iframe

<iframe> è lo strumento standard per includere intere pagine HTML esterne: video YouTube, mappe Google, widget social, applicazioni web. Supporta attributi avanzati come sandbox per sicurezza, loading=lazy per performance, allow per permessi specifici. È l'elemento più flessibile e moderno, supportato universalmente, e quello da preferire per quasi tutti i casi d'uso contemporanei.

Embed

<embed> nasceva per plugin browser (Flash, Java applets). Oggi è usato principalmente per PDF inline o contenuti multimediali legacy. Sintassi minimale: <embed src="..." type="...">. Non supporta contenuto di fallback nativo e ha meno controlli rispetto a iframe e object. È mantenuto principalmente per retrocompatibilità con contenuti vecchi e per qualche use case specifico come l'embedding di PDF.

Object

<object> è il più versatile dei tre: può embeddare PDF, immagini, video, pagine HTML, applet legacy. Supporta contenuto fallback nativo (testo dentro il tag mostrato se l'object non si carica) e parametri tramite <param> figli. Sintassi: <object data="..." type="...">Fallback</object>. Per PDF inline è spesso la scelta migliore grazie al fallback testuale graceful.

Object con fallback graceful

Object eccelle nel fallback testuale: il contenuto dentro <object> viene mostrato se il browser non può renderizzare il tipo di contenuto richiesto. Esempio per PDF: <object data="brochure.pdf" type="application/pdf" width="800" height="600"><p>Il tuo browser non supporta PDF inline. <a href="brochure.pdf">Scarica il PDF</a></p></object>. Soluzione robusta che funziona ovunque, anche su mobile dove molti browser preferiscono scaricare il PDF invece di renderizzarlo inline come desktop browser standard fanno.

Compatibilità storica

Embed era originariamente proprietario di Netscape, poi adottato da Microsoft, infine standardizzato in HTML5. Object è W3C standard dal 1997. Iframe esiste dal 1996. Oggi sono tutti universalmente supportati ma con use case distinti. La regola pratica: iframe per HTML, object con fallback per documenti (PDF), embed solo se necessario per retrocompatibilità con vecchio codice. Quando devi scegliere tra equivalenti, iframe e object sono più moderni e con migliore supporto degli attributi di sicurezza come sandbox.

PDF inline best practice

Per PDF inline le opzioni: object con fallback testuale (più robusto), iframe (più semplice ma senza fallback), embed (più datato). Considerazioni: su mobile molti browser scaricano il PDF invece di renderizzarlo, indipendentemente dal tag. Soluzioni: usare PDF.js (di Mozilla) per render uniformly cross-platform, mostrare anteprima JPG generata server-side con link al download, integrare viewer dedicati come ViewerJS. Best practice moderna: per PDF brevi (1-3 pagine), inline con fallback; per documenti lunghi, anteprima + download; per ecommerce con manuali, accordion con PDF embed lazy.

Sicurezza nei contenuti embedded

Tutti i tre elementi pongono rischi di sicurezza se mal configurati. Per iframe usa sandbox restrittivo. Per object e embed verifica che il MIME type sia esattamente quello atteso (server deve impostare Content-Type corretto). Per PDF da fonti non fidate considera PDF.js sandboxato. Non embedare mai contenuti da domini sconosciuti senza analisi del rischio. CSP frame-src limita quali domini possono essere iframed. Anti-clickjacking: tu nel tuo sito imposta X-Frame-Options DENY o frame-ancestors 'none' per impedire ad altri di iframe-are il tuo contenuto senza autorizzazione.

Best practice riassunto

Riassunto pratico delle scelte: per HTML embed (pagine web esterne, YouTube, mappe) usa iframe con loading=lazy e sandbox se necessario. Per PDF inline usa object con fallback link al download. Per immagini SVG con interattività complessa, object con type image/svg+xml mantiene gli script attivi nel SVG. Embed riservalo a contenuti legacy o se proprio necessario per compatibilità. Per ogni embed considera: ne vale la pena vs un semplice link? Quanto è pesante? Servizio terze parti affidabile? Implicazioni privacy/cookie? Lista mentale di domande prima di aggiungere ogni embed. Embed responsabile significa meno dipendenze, performance migliori, esperienza utente più pulita.

Procedura passo-passo

  1. Per pagine HTML esterne: usa iframe con sandbox e loading=lazy.
  2. Per video YouTube/Vimeo: iframe con allow="autoplay; encrypted-media" appropriato.
  3. Per PDF inline: prima opzione object con fallback testuale, alternativa embed o iframe.
  4. Per Mappe: iframe Google Maps con loading=lazy.
  5. Per immagini SVG con interazione: object con type="image/svg+xml".
  6. Specifica sempre width, height e title per accessibility.
  7. Aggiungi fallback testuale dentro object per browser che non possono renderizzare.

Errori comuni e come risolverli

  • Iframe per PDF su mobile: alcuni browser mobile non renderizzano PDF inline; offri sempre un link di download.
  • Embed senza type: il browser può non capire come gestire il contenuto; specifica MIME type.
  • Object senza fallback: perdi il vantaggio principale; aggiungi testo o link alternativo.
  • Title mancante in iframe: lettori schermo non possono annunciare il contenuto; sempre aggiungere title.
  • Usare embed per HTML: iframe è più adatto e moderno per pagine web esterne.

Domande frequenti

D: Quale usare per PDF?
R: Object con fallback testuale è la scelta più robusta; iframe funziona ma senza fallback.

D: Embed è deprecato?
R: No, ma raramente la scelta migliore. Iframe e object lo superano nella maggior parte dei casi.

D: Posso scriptare contenuto di iframe?
R: Solo se stessa origine. Cross-origin è bloccato da Same-Origin Policy.

D: Object supporta lazy loading?
R: No, l'attributo loading=lazy è solo per img e iframe.

Hai bisogno di aiuto?

Se vuoi sviluppo web con il team di G Tech Group, scrivici tramite il modulo di contatto.

Hai trovato utile quest'articolo?