Convertisseur HTML → JSX / React, gratuit

Comment ça marche

1. Collez du HTML : saisissez un extrait HTML standard (divs, formulaires, tables ou blocs complets) dans la zone d'entrée.
2. Choisissez les options : activez l'enveloppement React Fragment et le formatage pretty-print selon les besoins.
3. Obtenez le JSX instantanément : le convertisseur transforme automatiquement class → className, for → htmlFor, les chaînes style en objets style, et ferme les balises auto-fermantes.
4. Copiez dans votre projet : collez la sortie JSX directement dans vos composants React.

Pourquoi utiliser HTML → JSX ?

Lors de la migration de gabarits HTML vers React, la conversion manuelle est sujette aux erreurs. Oublier un seul className ou laisser une balise non fermée casse le build. Ce convertisseur gère automatiquement tous les changements requis, y compris la conversion des noms de propriétés CSS comme background-color en camelCase backgroundColor dans les attributs style, la transformation des chaînes de gestionnaires d'événements en références de fonctions et la fermeture correcte des éléments void. Cela accélère le prototypage, les migrations de code, et aide les développeurs peu familiers avec les différences de syntaxe JSX.

Conversions clés

• class → className: requis dans les composants React
• for → htmlFor: pour les éléments label
• chaînes style → objets: ex. : "color:red" → {color:'red'}
• Balises auto-fermantes: <br> → <br />
• Enveloppement par Fragment: <>…</> extérieur optionnel

Ce qu'est réellement JSX

JSX signifie « JavaScript XML ». C'est une extension syntaxique de JavaScript inventée par Jordan Walke chez Facebook en 2013 dans le cadre de l'annonce originale de React à la JSConf US. JSX vous permet d'écrire un balisage de type XML directement à l'intérieur du code JavaScript, <div className="hello">World</div> : et un transpileur (aujourd'hui presque toujours Babel) le compile en simples appels de fonction : React.createElement('div', {className: 'hello'}, 'World'). Le navigateur ne voit jamais JSX directement ; ce qui est livré est du JavaScript ordinaire.

La motivation initiale de Walke était que les langages de gabarit (Mustache, Handlebars, les anciennes directives d'Angular) étaient des citoyens de seconde classe du langage hôte : ils ne pouvaient pas utiliser nativement les boucles, les conditions ou les variables de JavaScript, de sorte que chacun réinventait les siennes. JSX a inversé la relation : au lieu de gabarits qui font occasionnellement du JavaScript, il vous a donné du JavaScript qui fait occasionnellement du balisage. Le fait que {condition && <Item />} soit une expression JS normale qui renvoie un élément React est l'idée porteuse.

Depuis React 17 (octobre 2020), le runtime JSX automatique signifie que vous n'avez plus besoin de import React from 'react' dans chaque fichier qui utilise JSX : Babel insère automatiquement les imports du runtime. JSX a aussi été adopté bien au-delà de React lui-même : Preact, Solid, Qwik, Hono JSX, Million, Lit et le .tsx de TypeScript consomment tous la même syntaxe. La spécification provisoire de JSX sur facebook.github.io/jsx est volontairement agnostique vis-à-vis du framework.

La liste complète des différences HTML → JSX

• Renommages de mots réservés. class → className (parce que class est réservé en JS). for → htmlFor (même raison, for est le mot-clé de boucle). Ce sont les deux qui piègent tout le monde en premier.
• Tous les autres attributs passent en camelCase. tabindex → tabIndex, readonly → readOnly, maxlength → maxLength, contenteditable → contentEditable.
• Deux exceptions importantes restent en kebab-case. Les attributs aria-* (aria-label, aria-hidden) et les attributs data-* (data-testid) conservent leur forme HTML. Idem pour xmlns.
• Les balises auto-fermantes sont obligatoires pour les éléments void : <br> devient <br />, <img> devient <img />, <input> devient <input />. JSX est strict comme XML là où HTML est permissif.
• Les styles inline prennent un objet, pas une chaîne. style="color: red; background-color: blue" devient style={{ color: 'red', backgroundColor: 'blue' }}. Notez trois choses : les doubles accolades (une pour l'expression JSX, une pour le littéral d'objet), les noms de propriété en camelCase, les valeurs de chaîne entre guillemets. Les valeurs numériques en pixels omettent l'unité : marginTop: 16, et non '16px'.
• Les gestionnaires d'événements passent en camelCase et prennent des références de fonction. onclick="handleClick()" devient onClick={handleClick} : notez l'absence de parenthèses. onClick={handleClick()} appellerait handleClick au moment du rendu et affecterait sa valeur de retour comme gestionnaire, ce qui est presque toujours un bug.
• Les commentaires utilisent {/* … */} à l'intérieur de JSX, et non <!-- … -->. La syntaxe de commentaire HTML n'a aucune signification à l'intérieur de JSX.
• Les fragments enveloppent plusieurs frères. Un composant doit renvoyer une racine unique, de sorte que plusieurs éléments de premier niveau nécessitent <>…</> (ou le plus long <React.Fragment>…</React.Fragment>) enroulé autour d'eux.
• Le rendu conditionnel utilise des expressions JS. {isVisible && <Item />} affiche l'élément uniquement si la condition est vraie ; {condition ? <A /> : <B />} choisit l'un des deux.
• Les accolades dans le texte doivent être échappées. L'{ littérale à l'intérieur du contenu textuel de JSX est interprétée comme le début d'une expression. Utilisez {'{'} ou un équivalent en entité HTML.

SVG, accessibilité et le reste

SVG fonctionne à l'intérieur de JSX avec la même règle camelCase pour la plupart des attributs : viewBox, strokeWidth, fillOpacity. Les exceptions notables : xlink:href utilise l'orthographe spéciale xlinkHref (désormais déconseillée au profit de href simple), et xmlns reste tel quel. Les attributs d'accessibilité suivent par exception la convention kebab-case propre à ARIA : aria-label, aria-describedby, role restent tels qu'écrits.

Pour le CSS, l'objet style inline de JSX est une option. La plupart des bases de code de production utilisent l'une des trois alternatives plus riches : les CSS Modules (noms de classes à portée par fichier compilés par le bundler), Tailwind CSS (classes utilitaires qui passent proprement via className), ou les bibliothèques CSS-in-JS comme styled-components, Emotion ou Vanilla Extract. Tailwind est devenu le choix le plus courant dans les nouveaux projets depuis 2022 ; les classes Tailwind ne nécessitent aucune conversion lors du passage de HTML à JSX : elles passent telles quelles sous forme de chaînes className ordinaires.

Pièges de conversion courants

• Les gestionnaires d'événements inline qui appellent la fonction. onclick="alert(1)" en HTML devient généralement onClick={() => alert(1)} en JSX, enveloppé dans une fonction fléchée pour que l'alerte se déclenche au clic, et non au rendu. Un convertisseur naïf qui produit onClick={alert(1)} fera apparaître l'alerte au moment du rendu plutôt que lorsque l'utilisateur clique. Ce convertisseur gère les cas courants, mais cela vaut la peine de jeter un œil à la sortie.
• Les commentaires HTML sont supprimés. La plupart des convertisseurs JSX suppriment les commentaires HTML plutôt que de les traduire en forme {/* */}, car cette dernière ne fonctionne qu'à des positions spécifiques à l'intérieur de JSX. Réajoutez les commentaires manuellement là où vous les voulez.
• Les renommages d'attributs SVG ne sont pas toujours gérés par les convertisseurs automatisés. stroke-width, fill-rule, clip-path, text-anchor nécessitent tous des formes en camelCase : vérifiez attentivement la sortie si vous collez du SVG provenant d'un jeu d'icônes comme Heroicons ou Lucide.
• Les attributs booléens. <input disabled> en HTML devient <input disabled /> en JSX. <input disabled="false"> en HTML est en réalité désactivé (n'importe quelle valeur l'active), mais en JSX disabled={false} est correctement désactivé : la sémantique de JSX est plus sensée que celle de HTML.
• Les entités HTML. © fonctionne dans le contenu textuel de JSX, mais utiliser le caractère Unicode littéral (©) est préférable.   fonctionne de la même façon.
• Le cas de tabindex. Devrait être tabIndex. Facile à oublier, car la valeur est souvent 0 ou -1 et a l'air numérique, mais le nom de l'attribut nécessite quand même le camelCase.

Quand y recourir

• Migrer des gabarits rendus côté serveur vers React. Coller un morceau du HTML d'un site existant et en obtenir du JSX est le cas d'usage canonique.
• Importer des icônes, des badges ou des exports d'outils de design. Heroicons, Lucide, le « Copier comme SVG » de Figma vous donnent tous du HTML/SVG brut qui nécessite la passe de renommage.
• Convertir des extraits Tailwind UI / Flowbite / DaisyUI de leurs exemples HTML vers JSX pour un projet React. Les classes Tailwind passent inchangées ; seuls les attributs structurels nécessitent une conversion.
• Initier des développeurs qui connaissent HTML mais pas JSX : voir les règles mécaniques appliquées automatiquement est plus rapide que de lire une liste de différences.
• Prototypage rapide lorsque vous avez ébauché du balisage en HTML brut à des fins d'esquisse et que vous le voulez à l'intérieur d'un composant React.

La sortie fonctionne pour n'importe quel consommateur de JSX : React, Preact, Solid, Qwik, Hono JSX, Million, le littéral de gabarit html de Lit (avec des ajustements mineurs). Elle ne fonctionne pas pour React Native, qui utilise des composants primitifs natifs comme <View> et <Text> plutôt que des éléments HTML.

Autres questions

Quelle est la différence entre JSX et HTML ?

HTML est un langage de balisage que le navigateur analyse directement. JSX est une syntaxe d'expression JavaScript qui se compile en appels React.createElement : il n'atteint jamais le navigateur sous forme de JSX. JSX a l'air strict comme XML (chaque balise doit se fermer, les attributs utilisent le camelCase) parce qu'il est analysé comme des expressions JavaScript, pas comme du HTML permissif. La similitude visuelle est intentionnelle, mais la sémantique sous-jacente est assez différente.

Dois-je encore importer React dans chaque fichier JSX ?

Plus depuis React 17 (octobre 2020), qui a introduit le runtime JSX automatique. Avec lui, Babel injecte pour vous les imports de runtime nécessaires, de sorte que les fichiers qui n'utilisent que JSX n'ont pas besoin d'un import React from 'react' en début de fichier. Le runtime classique reste disponible pour les chaînes d'outils plus anciennes. La plupart des nouveaux projets utilisent le runtime automatique.

Puis-je utiliser JSX sans React ?

Oui. JSX est une syntaxe générique dotée d'une spécification provisoire sur facebook.github.io/jsx, et de nombreux frameworks la consomment : Preact, Solid, Qwik, Hono JSX, Million, Lit, et la variante de gabarit balisé htm. Les frameworks diffèrent dans ce vers quoi JSX se compile (Preact utilise h(…), Solid se compile en primitives réactives à grain fin, etc.), mais la syntaxe est partagée.

Pourquoi style prend-il un objet au lieu d'une chaîne ?

Parce que la syntaxe d'expression de JSX fournit déjà des accolades pour intégrer des valeurs JavaScript, et un littéral d'objet est la représentation JS la plus naturelle d'un sac de propriétés. L'objet style autorise aussi les nombres (la plupart reçoivent automatiquement px) et les expressions JS, ce qu'une chaîne ne peut pas. Le compromis est la syntaxe à double accolade un peu maladroite style={{ … }} : les accolades extérieures pour « ceci est une expression JSX », les accolades intérieures pour le littéral d'objet.

Des données sont-elles envoyées à un serveur ?

Non. La logique de conversion est du JavaScript pur qui parcourt votre chaîne HTML et réécrit les attributs, le tout dans votre navigateur. Le HTML que vous collez ne quitte jamais la page : utile lors de la migration de gabarits internes propriétaires ou de balisage de composant avec des points de terminaison d'API intégrés.