Aperçu HTML / bac à sable de code, gratuit

Écrivez du HTML, du CSS et du JavaScript dans les éditeurs ci-dessous et voyez le résultat instantanément dans le panneau d'aperçu.

Aperçu

Comment ça marche

  1. Collez ou tapez du HTML : saisissez votre code HTML (documents complets, fragments, gabarits ou HTML d'e-mail) dans l'éditeur.
  2. Voyez le rendu en direct : le panneau d'aperçu montre exactement comment le navigateur rend votre HTML en temps réel.
  3. Itérez rapidement : éditez et prévisualisez dans une boucle serrée sans changer d'onglet ni enregistrer de fichier.

Pourquoi utiliser l'aperçu HTML ?

Quand vous écrivez du HTML pour des gabarits, des e-mails, des composants ou des pages statiques, vous avez besoin d'un retour constant sur le rendu du balisage. Ouvrir des fichiers dans un navigateur et rafraîchir manuellement casse votre flux. Cet outil d'aperçu HTML rend votre HTML instantanément pendant que vous tapez, offrant un aperçu visuel en direct dans la même fenêtre, idéal pour itérer rapidement sur des gabarits, déboguer des problèmes de mise en page et tester des e-mails HTML avant envoi.

Fonctionnalités

Questions fréquentes

Puis-je prévisualiser des e-mails HTML ?

Oui. Collez votre HTML d'e-mail, y compris les styles en ligne et les mises en page en tableaux. L'aperçu rend exactement comme le ferait un client de messagerie. Notez que les polices externes et certaines fonctionnalités CSS peuvent se comporter différemment dans les vrais clients de messagerie.

Le CSS et le JavaScript externes fonctionnent-ils ?

Les feuilles de style externes chargées via des balises <link> peuvent ne pas se charger à cause des restrictions CORS dans l'aperçu en sandbox. L'exécution JavaScript est limitée par le sandbox. Pour de meilleurs résultats, utilisez du CSS en ligne. Les ressources externes provenant de CDN autorisant l'accès cross-origin se chargeront normalement.

Puis-je l'utiliser pour tester des designs responsive ?

Oui. Faites glisser la largeur du panneau d'aperçu pour simuler différentes tailles d'écran, ou utilisez les préréglages de viewport (mobile, tablette, ordinateur) pour tester vos points de rupture responsive.

Comment fonctionne la prévisualisation en direct : iframe srcdoc

L'élément <iframe> a été introduit en HTML 4.0 (décembre 1997) pour intégrer un document dans un autre. Pendant deux décennies, le seul moyen de remplir une iframe était via l'attribut src pointant vers une URL. L'attribut srcdoc, vous permettant de passer le HTML de l'iframe en ligne sous forme de chaîne, a été ajouté en HTML5 (W3C Rec, octobre 2014) et est désormais pris en charge par tous les navigateurs modernes. srcdoc est ce qui rend possible un outil de prévisualisation HTML basé sur navigateur sans téléversement serveur : vous écrivez du HTML, l'outil l'enveloppe dans <iframe srcdoc="...">, le navigateur le rend dans un contexte isolé, et rien ne traverse le réseau.

L'attribut sandbox et le piège du same-origin

<iframe sandbox> a été introduit en HTML5 pour appliquer une politique de sécurité par iframe. Avec aucune valeur, la sandbox la plus restrictive s'applique : même origine restreinte (traitée comme une origine unique), scripts désactivés, formulaires désactivés, navigation de premier niveau désactivée, plugins désactivés, verrouillage du pointeur désactivé, popups désactivés, lecture automatique des médias désactivée. Vous réactivez en ajoutant des tokens : sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation, etc. Chaque token ouvre une capacité spécifique.

La combinaison à ne jamais utiliser est sandbox="allow-scripts allow-same-origin" simultanément : cela permet à JavaScript d'appeler document.domain et de remonter à la fenêtre parente, anéantissant complètement la sandbox. Les navigateurs avertissent à ce sujet dans DevTools lorsque vous définissez les deux. Cet outil de prévisualisation définit allow-scripts et explicitement PAS allow-same-origin, donc le JS utilisateur s'exécute mais ne peut pas lire ni écrire le DOM de la page parente, les cookies, localStorage, IndexedDB, ou les caches de service-worker.

Content Security Policy, la deuxième ligne de défense

Une défense séparée mais connexe est Content-Security-Policy, un en-tête de réponse HTTP introduit en W3C CSP Level 1 (Candidate Recommendation, novembre 2012). CSP Level 3 est le standard actuel. La directive clé pour les outils de prévisualisation : frame-src (quelles iframes peuvent être chargées) et script-src (quels scripts inline/externes peuvent s'exécuter). Même si une charge utile malveillante s'échappait de la sandbox, le CSP de la page hôte s'appliquerait toujours et interdirait la plupart des chemins d'exfiltration. Défense en profondeur : la sandbox isole le code de l'iframe, et le CSP de l'hôte limite ce que la page hôte peut faire si l'iframe l'a influencée d'une manière ou d'une autre.

Le HTML des clients e-mail est son propre monde

Une prévisualisation qui rend du HTML navigateur moderne ne rend pas du HTML e-mail. Les principaux clients e-mail utilisent des moteurs très différents : Gmail web utilise un moteur basé sur WebKit avec suppression de classes et support limité des balises <style> (ajouté en 2016). Apple Mail / iOS Mail utilisent WebKit, le moteur le plus permissif. Outlook desktop (2007 à 2019) rend le HTML e-mail via le moteur de rendu Microsoft Word : pas de support de bloc <style>, pas de flex/grid, pas d'éléments positionnés, pas d'animations ; les images de fond nécessitent des commentaires conditionnels VML. Cette particularité d'Outlook est le plus gros problème du développement e-mail. Outlook 365 web est du WebKit moderne. Le « nouveau Outlook » déployé en 2023-2024 utilise Edge WebView2. Pour de vraies prévisualisations de clients e-mail, utilisez un service payant comme Litmus ou Email on Acid.

Points de rupture responsifs à tester

Les conventions de breakpoints CSS media-query remontent à l'article « Responsive Web Design » d'Ethan Marcotte de mai 2010 dans A List Apart. Les deux frameworks dominants ont choisi des seuils différents :

La lignée des standards HTML

Référence rapide pour les standards contre lesquels votre prévisualisation effectue le rendu : HTML 2.0 (RFC 1866, novembre 1995), la première spécification officielle de Tim Berners-Lee, a établi l'ensemble de balises de base. HTML 4.01 (W3C Rec, décembre 1999) a ajouté <script>, <style>, <table>, frames. XHTML 1.0 (W3C Rec, janvier 2000) a tenté une sérialisation XML stricte, principalement abandonnée à partir de 2010. HTML5 (W3C Rec, octobre 2014) a ajouté des éléments sémantiques (<article>, <section>, <nav>), canvas, video/audio, web storage. En mai 2019, WHATWG a pris la relève de la W3C pour la gestion, et HTML est maintenant maintenu comme une Living Standard à html.spec.whatwg.org, mise à jour en continu.

Cas d'usage courants

Erreurs courantes

  1. Essayer de lire le contenu de l'iframe depuis le parent. Avec sandbox défini, les restrictions cross-origin le bloquent. L'iframe peut faire un postMessage sortant, mais le parent ne peut pas y entrer.
  2. Coller du CSS qui cible body et être surpris que les styles body de l'outil ne soient pas affectés. L'iframe est un document séparé avec son propre DOM.
  3. Ressources externes bloquées par CSP. Un <img src="https://example.com/x.png"> peut se charger correctement dans votre prévisualisation mais être bloqué lorsque vous copiez le même code sur un site de production verrouillé par CSP.
  4. Oublier que DOMContentLoaded se déclenche dans l'iframe, pas dans le parent. Les scripts à l'intérieur de l'iframe voient leur propre document, pas celui de l'outil.
  5. Définir à la fois allow-scripts et allow-same-origin dans un outil sandbox, anéantissant complètement l'objectif. Les navigateurs avertissent de cette combinaison dans DevTools.

Autres questions fréquemment posées

Pourquoi mon localStorage ne fonctionne-t-il pas dans la prévisualisation ?

localStorage et sessionStorage nécessitent allow-same-origin dans l'attribut sandbox. Comme combiner cela avec allow-scripts anéantirait la sandbox, cette prévisualisation bloque le stockage par conception. Votre code lèvera une SecurityError sur le premier localStorage.setItem. Pour tester du code dépendant du stockage, exécutez-le sur une vraie origine (un serveur de dev local par exemple).

Quelle version JavaScript la prévisualisation prend-elle en charge ?

Celle que votre navigateur supporte. L'iframe exécute le même moteur JS que la page parente, donc un utilisateur Chrome obtient V8, un utilisateur Firefox SpiderMonkey, un utilisateur Safari JavaScriptCore. Les fonctionnalités modernes (chaînage optionnel, top-level await, classes, async/await, syntaxe ES2024) fonctionnent si votre navigateur les supporte. Pour tester avec des cibles de navigateurs plus anciennes, collez la sortie transpilée de Babel ou swc.

Puis-je charger des scripts et feuilles de style externes ?

Oui pour la plupart des CDN publics. <script src="https://cdn.jsdelivr.net/..."> et <link href="https://cdn.tailwindcss.com" rel="stylesheet"> fonctionnent généralement parce que ces CDN définissent des en-têtes CORS permissifs. Les ressources qui nécessitent des credentials ou sont verrouillées par origine échoueront. Le panneau Network des DevTools de votre navigateur montre exactement quelles ressources ont chargé et lesquelles ont été bloquées.

En quoi est-ce différent de CodePen / JSFiddle / StackBlitz ?

Ce sont des services complets d'hébergement de code avec fonctionnalités save / share / fork / collaboration et qui nécessitent des comptes. Cet outil est un brouillon mono-page : pas de compte, pas de sauvegarde, pas de partage, pas d'analytique. Collez, prévisualisez, itérez, fermez l'onglet. Pour quelque chose que vous voulez garder ou partager, CodePen reste la meilleure option.

Mon code est-il téléversé quelque part ?

Non. Le HTML / CSS / JS que vous collez est enveloppé dans <iframe srcdoc="..."> sur la même page et rendu dans une origine unique en sandbox dans votre navigateur. Aucun appel réseau ne transporte votre contenu. Les ressources externes que votre HTML référence (images, scripts, feuilles de style) sont récupérées par votre navigateur de la même façon qu'elles le seraient sur n'importe quelle page web, mais le code source lui-même ne quitte jamais la page.

Outils associés

Convertisseur code → image, gratuit Minifieur HTML, gratuit Prévisualisation Markdown en ligne, gratuite Générateur de table HTML, gratuit