Conversor gratuito de HTML para JSX/React

Como funciona

1. Cole HTML : insira um trecho de HTML padrão (divs, formulários, tabelas ou blocos completos) na área de entrada.
2. Escolha as opções : ative o envolvimento em React Fragment e a formatação pretty-print conforme a necessidade.
3. Obtenha o JSX instantaneamente : o conversor transforma automaticamente class → className, for → htmlFor, strings style em objetos style, e fecha as tags auto-fechadas.
4. Copie para o seu projeto : cole a saída JSX diretamente nos seus componentes React.

Por que usar HTML → JSX ?

Ao migrar templates HTML para React, a conversão manual é sujeita a erros. Esquecer um único className ou deixar uma tag não fechada quebra o build. Este conversor lida automaticamente com todas as mudanças necessárias, incluindo a conversão dos nomes de propriedades CSS como background-color em camelCase backgroundColor nos atributos style, a transformação das strings de manipuladores de eventos em referências de funções e o fechamento correto dos elementos void. Isso acelera a prototipagem, as migrações de código e ajuda desenvolvedores pouco familiarizados com as diferenças de sintaxe JSX.

Conversões-chave

• class → className: obrigatório em componentes React
• for → htmlFor: para elementos label
• strings style → objetos: ex. : "color:red" → {color:'red'}
• Tags auto-fechadas: <br> → <br />
• Envolvimento por Fragment: <>…</> externo opcional

O que o JSX realmente é

JSX significa «JavaScript XML». É uma extensão sintática do JavaScript inventada por Jordan Walke no Facebook em 2013, como parte do anúncio original do React na JSConf US. O JSX permite escrever marcação parecida com XML diretamente dentro do código JavaScript, <div className="hello">World</div>, e um transpilador (hoje quase sempre o Babel) o compila para chamadas de função simples: React.createElement('div', {className: 'hello'}, 'World'). O navegador nunca vê o JSX diretamente; o que é enviado é JavaScript comum.

A motivação original de Walke era que as linguagens de template (Mustache, Handlebars, as antigas diretivas do Angular) eram cidadãs de segunda classe da linguagem hospedeira, não conseguiam usar nativamente os loops, condicionais ou variáveis do JavaScript, então cada uma reinventava a sua própria. O JSX inverteu a relação: em vez de templates que ocasionalmente fazem JavaScript, ele lhe deu JavaScript que ocasionalmente faz marcação. O fato de {condition && <Item />} ser uma expressão JS normal que retorna um elemento React é a ideia que sustenta tudo.

Desde o React 17 (outubro de 2020), o runtime automático de JSX significa que você não precisa mais dar import React from 'react' em todo arquivo que usa JSX, o Babel insere as importações do runtime automaticamente. O JSX também foi adotado bem além do próprio React: Preact, Solid, Qwik, Hono JSX, Million, Lit e o .tsx do TypeScript consomem todos a mesma sintaxe. A spec preliminar do JSX em facebook.github.io/jsx é intencionalmente agnóstica de framework.

A lista completa das diferenças entre HTML→JSX

• Renomeações de palavras reservadas. class → className (porque class é reservada em JS). for → htmlFor (mesmo motivo, for é a palavra-chave de loop). Essas são as duas com que todo mundo se machuca primeiro.
• Todos os outros atributos viram camelCase. tabindex → tabIndex, readonly → readOnly, maxlength → maxLength, contenteditable → contentEditable.
• Duas exceções importantes permanecem em kebab-case. Os atributos aria-* (aria-label, aria-hidden) e os atributos data-* (data-testid) mantêm a sua forma HTML. O mesmo vale para xmlns.
• As tags autofechadas são obrigatórias para os elementos void: <br> vira <br />, <img> vira <img />, <input> vira <input />. O JSX é rigoroso como XML, onde o HTML é tolerante.
• Os estilos inline recebem um objeto, não uma string. style="color: red; background-color: blue" vira style={{ color: 'red', backgroundColor: 'blue' }}. Note três coisas: chaves duplas (uma para a expressão JSX, uma para o objeto literal), nomes de propriedade em camelCase, valores de string entre aspas. Os valores numéricos em pixels omitem a unidade: marginTop: 16, e não '16px'.
• Os manipuladores de eventos viram camelCase e recebem referências de função. onclick="handleClick()" vira onClick={handleClick}: note os parênteses ausentes. onClick={handleClick()} chamaria handleClick no momento da renderização e atribuiria o seu valor de retorno como o manipulador, o que quase sempre é um bug.
• Os comentários usam {/* … */} dentro do JSX, não <!-- … -->. A sintaxe de comentário do HTML não tem significado dentro do JSX.
• Os fragments envolvem múltiplos irmãos. Um componente deve retornar uma única raiz, então múltiplos elementos de nível superior precisam de <>…</> (ou o mais longo <React.Fragment>…</React.Fragment>) envolvendo-os.
• A renderização condicional usa expressões JS. {isVisible && <Item />} renderiza o item apenas se a condição for verdadeira; {condition ? <A /> : <B />} escolhe um de dois.
• As chaves no texto precisam de escape. O { literal dentro do conteúdo de texto JSX é interpretado como o início de uma expressão. Use {'{'} ou um equivalente em entidade HTML.

SVG, acessibilidade e o resto

O SVG funciona dentro do JSX com a mesma regra de camelCase para a maioria dos atributos, viewBox, strokeWidth, fillOpacity. As exceções notáveis: xlink:href usa a grafia especial xlinkHref (agora obsoleta em favor do href simples), e xmlns permanece como está. Os atributos de acessibilidade seguem a convenção kebab-case do próprio ARIA por exceção: aria-label, aria-describedby, role permanecem todos como escritos.

Para CSS, o objeto style inline do JSX é uma opção. A maioria das bases de código de produção usa uma de três alternativas mais ricas: CSS Modules (nomes de classe com escopo por arquivo, compilados pelo bundler), Tailwind CSS (classes utilitárias que passam de forma limpa via className) ou bibliotecas de CSS-in-JS como styled-components, Emotion ou Vanilla Extract. O Tailwind se tornou a escolha mais comum em novos projetos desde 2022; as classes do Tailwind não precisam de nenhuma conversão ao mover HTML para JSX, elas passam direto como strings className comuns.

Ciladas comuns de conversão

• Manipuladores de eventos inline que chamam a função. onclick="alert(1)" no HTML normalmente vira onClick={() => alert(1)} no JSX, envolvido em uma arrow function para que o alerta dispare no clique, e não na renderização. Um conversor ingênuo que produz onClick={alert(1)} vai abrir o alerta no momento da renderização em vez de quando o usuário clica. Este conversor lida com os casos comuns, mas vale a pena dar uma olhada na saída.
• Os comentários HTML são descartados. A maioria dos conversores de JSX remove os comentários HTML em vez de traduzi-los para a forma {/* */}, porque esta última só funciona em posições específicas dentro do JSX. Adicione os comentários de volta manualmente onde você os quiser.
• As renomeações de atributos SVG nem sempre são tratadas pelos conversores automatizados. stroke-width, fill-rule, clip-path, text-anchor precisam todos das formas camelCase, verifique a saída com cuidado se você está colando SVG de um conjunto de ícones como o Heroicons ou o Lucide.
• Atributos booleanos. <input disabled> no HTML vira <input disabled /> no JSX. <input disabled="false"> no HTML está, na verdade, desabilitado (qualquer valor o ativa), mas no JSX disabled={false} está corretamente desligado, a semântica do JSX é mais sensata do que a do HTML.
• Entidades HTML. © funciona no conteúdo de texto JSX, mas usar o caractere Unicode literal (©) é preferível.   funciona da mesma forma.
• O caso do tabindex. Deveria ser tabIndex. Fácil de esquecer porque o valor é frequentemente 0 ou -1 e parece numérico, mas o nome do atributo ainda precisa de camelCase.

Quando você recorreria a isto

• Migrar templates renderizados no servidor para o React. Colar um trecho do HTML de um site existente e obter JSX é o caso de uso canônico.
• Puxar ícones, badges ou exportações de ferramentas de design. O Heroicons, o Lucide e o «Copiar como SVG» do Figma dão a você HTML/SVG bruto que precisa da passagem de renomeação.
• Converter trechos do Tailwind UI / Flowbite / DaisyUI dos seus exemplos em HTML para JSX em um projeto React. As classes do Tailwind passam sem alteração; apenas os atributos estruturais precisam de conversão.
• Integrar desenvolvedores que conhecem HTML mas não JSX: ver as regras mecânicas aplicadas automaticamente é mais rápido do que ler uma lista de diferenças.
• Prototipagem rápida quando você rascunhou a marcação em HTML simples para fins de esboço e quer colocá-la dentro de um componente React.

A saída funciona para qualquer consumidor de JSX, React, Preact, Solid, Qwik, Hono JSX, Million, o template literal html do Lit (com pequenos ajustes). Ela não funciona para o React Native, que usa componentes primitivos nativos como <View> e <Text> em vez de elementos HTML.

Mais perguntas

Qual é a diferença entre JSX e HTML?

O HTML é uma linguagem de marcação que o navegador analisa diretamente. O JSX é uma sintaxe de expressão JavaScript que compila para chamadas React.createElement, ele nunca chega ao navegador como JSX. O JSX parece rigoroso como XML (toda tag deve fechar, os atributos usam camelCase) porque é analisado como expressões JavaScript, não como HTML tolerante. A semelhança visual é intencional, mas a semântica subjacente é bem diferente.

Ainda preciso importar o React em todo arquivo JSX?

Não desde o React 17 (outubro de 2020), que introduziu o runtime automático de JSX. Com ele, o Babel injeta as importações de runtime necessárias para você, então os arquivos que só usam JSX não precisam de um import React from 'react' no topo do arquivo. O runtime clássico ainda está disponível para cadeias de ferramentas mais antigas. A maioria dos novos projetos usa o runtime automático.

Posso usar JSX sem o React?

Sim. O JSX é uma sintaxe genérica com uma spec preliminar em facebook.github.io/jsx, e muitos frameworks o consomem: Preact, Solid, Qwik, Hono JSX, Million, Lit e a variante de template marcado htm. Os frameworks diferem no que o JSX compila (o Preact usa h(…), o Solid compila para primitivas reativas de granularidade fina etc.), mas a sintaxe é compartilhada.

Por que o style recebe um objeto em vez de uma string?

Porque a sintaxe de expressão do JSX já fornece chaves para embutir valores JavaScript, e um objeto literal é a representação JS mais natural de um conjunto de propriedades. O objeto style também permite números (a maioria recebe px automaticamente) e expressões JS, o que uma string não pode. A desvantagem é a sintaxe de chaves duplas um tanto desajeitada style={{ … }}, chaves externas para «isto é uma expressão JSX», chaves internas para o objeto literal.

Algo é enviado a um servidor?

Não. A lógica de conversão é JavaScript puro que percorre a sua string HTML e reescreve os atributos, tudo no seu navegador. O HTML que você cola nunca sai da página, útil ao migrar templates internos proprietários ou marcação de componentes com endpoints de API embutidos.