L’éditeur ci-dessus est un éditeur de documents HTML complets avec aperçu live : tapez à gauche, et la page que vous construisez se rend à droite. Tout fonctionne dans votre navigateur — rien à installer, aucun compte, et rien de ce que vous écrivez ne quitte votre machine. L’aperçu est une vraie frame de navigateur : ce que vous voyez est ce qu’un visiteur verrait.
Écrire et exécuter du HTML en ligne
Tout ce que vous mettez dans l’éditeur est traité comme un document HTML complet — doctype, <head> et <body> compris. C’est plus important que ça n’en a l’air : balises meta, favicons, titres et feuilles de style ne se comportent correctement que dans un vrai <head>, et cet éditeur rend le vôtre fidèlement. Le modèle de départ contient déjà le squelette utile, et le menu des modèles propose des documents prêts — un formulaire d’inscription, un tableau de données, une image responsive, une démo de favicon et un exemple de balises sociales — à démonter pour pièces.
Avec Exécution auto activée, l’aperçu se rafraîchit environ une demi-seconde après la dernière frappe : ça paraît vivant sans clignoter à chaque touche. Vous préférez le contrôle manuel ? Désactivez-la et appuyez sur Exécuter (ou Ctrl/Cmd + Entrée) quand vous voulez rendre. Ouvrir dans un nouvel onglet sort le document courant dans une fenêtre complète — pratique pour tester un formulaire à taille réelle ou partager son écran pendant un cours.
Sortie console et erreurs de script
Le console.log des scripts de votre document apparaît dans la console sous l’espace de travail, avec les avertissements et les erreurs. Quand un script lève une exception, le message arrive avec la ligne et la colonne de la panne — les numéros correspondent à l’éditeur, pas à une représentation interne, parce que l’aperçu injecte son pont de rapport en une seule ligne avant votre code. Les rejets de promesses non gérés sont captés aussi. Si vous apprenez avec le parcours JavaScript (actuellement en anglais), ce panneau impose la même discipline de console que les devtools, sans leur chrome intimidant.
Vérifiez votre mise en page aux largeurs réelles
Les boutons de largeur au-dessus de l’aperçu rendent votre document en largeur téléphone (390 px), tablette (820 px) ou ordinateur (1280 px), centré et encadré pour que la contrainte saute aux yeux. C’est le moyen le plus rapide de sentir pourquoi max-width, les grilles fluides et la balise viewport du meta comptent : réduisez le cadre et regardez une page bien construite se réorganiser pendant qu’une page fragile déborde. Le défaut Adaptatif remplit simplement le panneau — assez large déjà sur un ordinateur portable pour la plupart des mises en page de bureau.
Pourquoi le head compte
Parce que c’est un éditeur de documents entiers, le <head> est le vôtre — et c’est là qu’une part étonnante du vrai travail se passe. Le modèle favicon, par exemple, définit une icône emoji entièrement dans une seule balise link, sans fichier image ; pour le tableau complet, notre guide « ajouter une favicon en HTML » (en anglais) détaille formats, tailles et les erreurs qui font échouer une icône en silence. Le modèle meta montre les balises que les moteurs de recherche et les aperçus de messageries lisent vraiment. Éditer le head en direct, avec retour immédiat, fait la différence entre mémoriser des règles et les voir fonctionner.
Votre travail est sauvegardé — localement
Le document en cours est conservé dans le stockage local du navigateur : un rechargement accidentel ou un onglet fermé n’est pas du travail perdu. Réinitialiser remet le modèle de départ et efface la sauvegarde. Partager emballe tout le document dans le lien lui-même (le fragment après le # n’atteint jamais un serveur) pour transmettre une copie exacte — un formateur peut envoyer une page cassée à réparer, ou garder un extrait sur une seconde machine. Télécharger sauvegarde en index.html, et Ouvrir charge n’importe quel fichier .html de votre ordinateur.
Questions fréquentes
Peut-on mettre du CSS et du JavaScript dans le HTML ? Oui — les blocs <style> et <script> fonctionnent comme dans tout navigateur. Le Web Playground sépare HTML, CSS et JS en trois fichiers si vous préférez cette organisation.
Faut-il internet ? Seulement pour charger la page. Ensuite tout — édition, aperçu, console — marche hors ligne.
Mon HTML est-il envoyé quelque part ? Non. L’aperçu est généré dans votre navigateur. Les documents sauvegardés vivent dans le stockage local, et les liens de partage transportent le code dans l’URL elle-même.
Peut-on tester formulaires, images et liens ? Les formulaires sont soumis localement, les images se chargent depuis toute URL référencée, les liens s’ouvrent dans de nouveaux onglets. Le bac à sable garde l’aperçu isolé du reste du site : les expériences ne fuient nulle part.
Pourquoi ma page diffère de mon fichier local ? Si votre fichier s’appuie sur des fichiers voisins (un styles.css local, des images dans un dossier), ces chemins se résolvent dans le bac à sable — collez le CSS pertinent dans un bloc <style> pour voir le vrai résultat.