Anteprima HTML / Campo di gioco del codice

Scrivi HTML, CSS e JavaScript negli editor sottostanti e visualizza il risultato istantaneamente nel pannello di anteprima.

Anteprima

Come funziona

  1. Incolla o digita HTML: inserisci il tuo codice HTML, documenti completi, frammenti, template o HTML di email, nell'editor.
  2. Visualizza il rendering live: il pannello di anteprima mostra esattamente come il browser renderizza il tuo HTML in tempo reale.
  3. Itera rapidamente: modifica e visualizza l'anteprima in un ciclo serrato senza cambiare scheda né salvare file.

Perché usare l'anteprima HTML?

Quando scrivi HTML per template, email, componenti o pagine statiche, hai bisogno di un feedback costante su come viene renderizzato il markup. Aprire file in un browser e aggiornare manualmente interrompe il tuo flusso. Questo strumento di anteprima HTML renderizza il tuo HTML istantaneamente mentre digiti, offrendo un'anteprima visiva live nella stessa finestra, ideale per iterare rapidamente sui template, debuggare problemi di layout e testare le email HTML prima di inviarle.

Funzionalità

Domande frequenti

Posso visualizzare in anteprima email HTML?

Sì. Incolla il tuo HTML di email comprensivo di stili in linea e layout basati su tabelle. L'anteprima si renderizza esattamente come farebbe un client di posta. Nota che i caratteri esterni e alcune funzionalità CSS potrebbero comportarsi diversamente nei client di posta reali.

CSS e JavaScript esterni funzionano?

I fogli di stile esterni caricati tramite tag <link> potrebbero non caricarsi a causa delle restrizioni CORS nell'anteprima in sandbox. L'esecuzione JavaScript è limitata dal sandbox. Per i migliori risultati, usa CSS in linea. Le risorse esterne provenienti da CDN che consentono l'accesso cross-origin si caricano normalmente.

Posso usarlo per testare design responsive?

Sì. Trascina la larghezza del pannello di anteprima per simulare diverse dimensioni di schermo, oppure usa i preset di viewport (mobile, tablet, desktop) per testare i tuoi breakpoint responsive.

Come funziona l'anteprima live: iframe srcdoc

L'elemento <iframe> è stato introdotto in HTML 4.0 (dicembre 1997) per incorporare un documento dentro un altro. Per due decenni l'unico modo di popolare un iframe era tramite l'attributo src che puntava a un URL. L'attributo srcdoc, che ti permette di passare l'HTML dell'iframe inline come stringa, è stato aggiunto in HTML5 (W3C Rec, ottobre 2014) ed è ora supportato da ogni browser moderno. srcdoc è ciò che rende possibile uno strumento di anteprima HTML basato su browser senza upload al server: scrivi HTML, lo strumento lo avvolge in <iframe srcdoc="...">, il browser lo renderizza in un contesto isolato, e niente attraversa la rete.

L'attributo sandbox e la trappola del same-origin

<iframe sandbox> è stato introdotto in HTML5 per applicare una politica di sicurezza per iframe. Con nessun valore, si applica la sandbox più restrittiva: same-origin limitato (trattato come un'origine unica), script disabilitati, form disabilitati, navigazione di primo livello disabilitata, plugin disabilitati, blocco del puntatore disabilitato, popup disabilitati, riproduzione automatica di media disabilitata. Riattivi aggiungendo token: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation ecc. Ogni token apre una capacità specifica.

La combinazione da non usare mai è sandbox="allow-scripts allow-same-origin" simultaneamente: questo permette a JavaScript di chiamare document.domain e risalire alla finestra genitore, sconfiggendo completamente la sandbox. I browser avvertono di questo in DevTools quando imposti entrambi. Questo strumento di anteprima imposta allow-scripts e esplicitamente NON allow-same-origin, quindi il JS dell'utente funziona ma non può leggere o scrivere il DOM della pagina genitore, cookie, localStorage, IndexedDB o cache di service-worker.

Content Security Policy, la seconda linea di difesa

Una difesa separata ma correlata è la Content-Security-Policy, un header di risposta HTTP introdotto in W3C CSP Level 1 (Candidate Recommendation, novembre 2012). CSP Level 3 è lo standard attuale. La direttiva chiave per gli strumenti di anteprima: frame-src (quali iframe possono essere caricati) e script-src (quali script inline/esterni possono essere eseguiti). Anche se un payload malevolo sfuggisse alla sandbox, il CSP della pagina ospite si applicherebbe comunque e proibirebbe la maggior parte dei percorsi di esfiltrazione. Difesa in profondità: la sandbox isola il codice dell'iframe, e il CSP dell'host limita ciò che la pagina ospite può fare se l'iframe l'ha influenzata in qualche modo.

L'HTML dei client di posta è il suo mondo

Un'anteprima che renderizza HTML moderno per browser non renderizza HTML di posta. I principali client di posta usano motori molto diversi: Gmail web usa un renderer basato su WebKit con class-stripping e supporto limitato dei tag <style> (aggiunto nel 2016). Apple Mail / iOS Mail usano WebKit, il renderer più permissivo. Outlook desktop (2007 al 2019) renderizza l'HTML di posta tramite il motore di rendering Microsoft Word: nessun supporto per blocchi <style>, nessun flex/grid, nessun elemento posizionato, nessuna animazione; le immagini di sfondo richiedono commenti condizionali VML. Questa stranezza di Outlook è il più grande problema nello sviluppo di posta. Outlook 365 web è WebKit moderno. Il «nuovo Outlook» distribuito nel 2023-2024 usa Edge WebView2. Per anteprime reali di client di posta, usa un servizio a pagamento come Litmus o Email on Acid.

Breakpoint responsive da testare

Le convenzioni di breakpoint CSS media-query risalgono all'articolo «Responsive Web Design» di Ethan Marcotte del maggio 2010 in A List Apart. I due framework dominanti hanno scelto tagli diversi:

La discendenza degli standard HTML

Riferimento rapido per gli standard contro cui la tua anteprima sta renderizzando: HTML 2.0 (RFC 1866, novembre 1995), la prima specifica ufficiale di Tim Berners-Lee, stabilì l'insieme di tag di base. HTML 4.01 (W3C Rec, dicembre 1999) aggiunse <script>, <style>, <table>, frame. XHTML 1.0 (W3C Rec, gennaio 2000) tentò una serializzazione XML rigorosa, per lo più abbandonata entro il 2010. HTML5 (W3C Rec, ottobre 2014) aggiunse elementi semantici (<article>, <section>, <nav>), canvas, video/audio, web storage. Nel maggio 2019, WHATWG ha assunto la gestione da W3C, e HTML è ora mantenuto come Living Standard su html.spec.whatwg.org, aggiornato continuamente.

Casi d'uso comuni

Errori comuni

  1. Tentare di leggere il contenuto dell'iframe dal genitore. Con sandbox impostato, le restrizioni cross-origin lo bloccano. L'iframe può fare postMessage in uscita, ma il genitore non può raggiungere dentro.
  2. Incollare CSS che mira a body ed essere sorpreso che gli stili body dello strumento non siano influenzati. L'iframe è un documento separato con il suo DOM.
  3. Risorse esterne bloccate dal CSP. Un <img src="https://example.com/x.png"> può caricarsi bene nella tua anteprima ma essere bloccato quando copi lo stesso codice in un sito di produzione bloccato da CSP.
  4. Dimenticare che DOMContentLoaded si scatena nell'iframe, non nel genitore. Gli script nell'iframe vedono il loro document, non quello dello strumento.
  5. Impostare sia allow-scripts che allow-same-origin in uno strumento sandbox, sconfiggendo completamente lo scopo. I browser avvertono di questa combinazione in DevTools.

Altre domande frequenti

Perché il mio localStorage non funziona nell'anteprima?

localStorage e sessionStorage richiedono allow-same-origin nell'attributo sandbox. Poiché combinarlo con allow-scripts sconfiggerebbe la sandbox, questa anteprima blocca lo storage di proposito. Il tuo codice lancerà un SecurityError alla prima localStorage.setItem. Per testare codice dipendente da storage, eseguilo su un'origine reale (un server di dev locale, per esempio).

Quale versione di JavaScript supporta l'anteprima?

Qualsiasi versione supportata dal tuo browser. L'iframe esegue lo stesso motore JS della pagina genitore, quindi un utente Chrome ottiene V8, un utente Firefox SpiderMonkey, un utente Safari JavaScriptCore. Funzionalità moderne (optional chaining, top-level await, classi, async/await, sintassi ES2024) funzionano se il tuo browser le supporta. Per test mirati a browser più vecchi, incolla output transpilato da Babel o swc.

Posso caricare script e fogli di stile esterni?

Sì per la maggior parte dei CDN pubblici. <script src="https://cdn.jsdelivr.net/..."> e <link href="https://cdn.tailwindcss.com" rel="stylesheet"> di solito funzionano perché quei CDN impostano header CORS permissivi. Le risorse che richiedono credenziali o sono bloccate per origine falliranno. Il pannello Network nelle DevTools del tuo browser mostra esattamente quali risorse sono state caricate e quali bloccate.

In cosa è diverso da CodePen / JSFiddle / StackBlitz?

Quelli sono servizi completi di hosting di codice con funzionalità di salvataggio / condivisione / fork / collaborazione e richiedono account. Questo strumento è uno scratchpad a pagina singola: nessun account, nessun salvataggio, nessuna condivisione, nessuna analytics. Incolla, anteprima, itera, chiudi il tab. Per qualcosa che vuoi mantenere o condividere, CodePen è ancora l'opzione migliore.

Il mio codice viene caricato da qualche parte?

No. L'HTML / CSS / JS che incolli viene avvolto in <iframe srcdoc="..."> sulla stessa pagina e renderizza in un'origine unica in sandbox nel tuo browser. Nessuna chiamata di rete trasporta il tuo contenuto. Le risorse esterne a cui il tuo HTML si riferisce (immagini, script, fogli di stile) sono recuperate dal tuo browser nello stesso modo in cui sarebbero su qualsiasi pagina web, ma il codice sorgente stesso non lascia mai la pagina.

Strumenti correlati

Convertitore da codice a immagine Minificatore HTML Anteprima Markdown gratuita online Generatore tabelle HTML