Conversor de JSON para XML
O que é conversão de JSON para XML?
JSON to XML converte dados JSON estruturados em marcação XML para que informações circulem entre sistemas que esperam formatos de troca diferentes. JSON usa objetos, arrays, números, strings, booleanos e null, enquanto XML usa elementos, atributos, nós de texto e namespaces. Por isso a conversão nem sempre é um para um: nomes de arrays, mapeamento de atributos, valores vazios, caracteres especiais e ordem precisam de representação sensata. A ferramenta é útil em integrações próximas de SOAP, sistemas corporativos legados, migração de dados, payloads de teste e documentação. Em produção, valide o resultado contra o XSD, contrato de API ou formato do parceiro.
Como Usar
Como usar
- Cole ou insira dados JSON na caixa de entrada à esquerda
- Opcionalmente, personalize o nome do elemento raiz
- Selecione o tamanho da indentação (2 espaços, 4 espaços ou Tab)
- O XML convertido é exibido à direita com destaque de sintaxe
- Clique em Copy ou Download para salvar o resultado
Verificações de Conversão
- Revise arrays, valores nulos e campos semelhantes a atributos após a conversão; JSON e XML não modelam dados exatamente da mesma forma.
- Escolha um nome estável para o elemento raiz antes de copiar o XML para uma requisição de API, arquivo de configuração ou fixture de teste.
Casos de uso
Princípio técnico
JSON (RFC 8259, derivado de literais de objetos JavaScript) e XML (W3C XML 1.0, originalmente de 1998) são ambos formatos de serialização em árvore, mas suas gramáticas diferem. JSON possui objetos (mapas de chave/valor com chaves string), arrays (listas ordenadas) e seis tipos escalares (string, number, boolean, null e os tipos estruturais). XML possui elementos (pares de tags de abertura/fechamento que envolvem texto ou elementos filhos), atributos (pares nome/valor na tag de abertura), nós de texto, comentários, instruções de processamento e seções CDATA. A conversão é uma transformação estrutural sem resposta canônica — toda convenção existente (BadgerFish, JSONML, codificação SOAP/RPC, esquema plano do OOXML, formato linkbase do XBRL) é uma regra diferente para a mesma entrada. A decisão 'atributo versus elemento filho' é a ambiguidade central. Os únicos metadados de JSON residem no nome da chave, então um objeto JSON como `{"id": "42", "name": "Alice", "admin": true}` não indica quais chaves são 'metadados' e quais são 'dados'. Três convenções comuns: (1) o padrão da página — escalares se tornam conteúdo de texto, enquanto a chave JSON original de um conjunto de atributos aninhados (reconhecido por ser um objeto não-array cujos valores são apenas escalares) se torna um atributo XML prefixado com `@` (convenção BadgerFish). (2) JSONML — todo objeto JSON se torna um elemento com a chave 'tag' como nome do elemento, a chave 'attr' como mapa de atributos e entradas filhas como filhos. (3) oData / Atom — objetos JSON se tornam elementos e arrays são incorporados com um elemento wrapper de nome de array. Cada regra é comprovadamente correta para algum consumidor downstream e comprovadamente incorreta para outro, é por isso que nenhum conversor para XML foi universalmente aceito. Arrays são a segunda ambiguidade. Arrays JSON são listas ordenadas; XML não possui um tipo nativo de array. As três soluções padrão: (a) repetir elementos filhos (o padrão da página, a convenção OOXML/SOAP): `[1, 2, 3]` → `<root><item>1</item><item>2</item><item>3</item></root>`. (b) Envolver em um contêiner: `<root><items><item>1</item>...</items></root>`. (c) Codificar o array como uma string delimitada e documentar o delimitador (CSV-em-XML, apenas quando o consumidor o analisa). Cada opção é correta para um XSD downstream diferente; a etapa de conversão precisa saber qual emitir. Os nomes dos elementos XML devem ser tokens QName válidos (XML 1.0 §2.3 / XML Namespaces 1.0 §3): começar com uma letra, sublinhado ou dois-pontos, seguido de letras, dígitos, hífens, sublinhados, pontos ou dois-pontos. JSON permite chaves como '123' ou 'first name' que violam isso — o conversor deve renomeá-las (slugificar para first_name, prefixar com _) ou falhar. O conteúdo de strings JSON também precisa de escape de entidades no texto do elemento e nos valores dos atributos: `&` → `&`, `<` → `<`, `>` → `>` (obrigatório apenas em texto no XML mais antigo, mas sempre seguro), `"` → `"` e `'` → `'` em atributos, e qualquer caractere fora do intervalo da codificação como `&#xHHHH;`. As cinco entidades embutidas mais referências numéricas de caracteres são obrigatórias em XML; as entidades nomeadas adicionais do HTML (` `, `©`) não estão definidas em XML simples e precisam de um DOCTYPE explícito se utilizadas. O documento de saída também precisa de um prólogo e declarações de namespace: `<?xml version="1.0" encoding="UTF-8"?>` primeiro, depois quaisquer declarações xmlns. Se o sistema alvo usar namespaces (SOAP usa `http://www.w3.org/2003/05/soap-envelope`, XSLT usa `http://www.w3.org/1999/XSL/Transform`), os mapeamentos de prefixo são adicionados como atributos `xmlns:prefix="uri"` no elemento raiz. JSON não possui conceito de namespace, então a escolha de qual URI usar é específica do projeto. Para valores vazios, null em JSON geralmente é expresso como `<key xsi:nil="true"/>` (a convenção do XML Schema) ou `<key></key>` (a convenção de elemento vazio). O conversor escolhe um; a resposta correta depende da validação XSD do consumidor. Para a direção inversa (XML → JSON), as mesmas ambiguidades ao contrário: atributos mapeiam para uma chave `@attributes` no BadgerFish, CDATA mapeia para uma chave `$` ou `#text`, elementos de conteúdo misto (texto + elementos filhos intercalados) não possuem representação JSON limpa e geralmente são emitidos como uma concatenação de strings. Conversores do mundo real sempre expõem opções de 'chave de atributo', 'chave de texto', 'wrapper de array' — não há como contornar isso.
- JSON (RFC 8259) e XML (W3C XML 1.0, 1998) são ambos formatos de serialização em árvore; a conversão é uma transformação estrutural sem resposta canônica, então múltiplas convenções (BadgerFish, JSONML, SOAP, OOXML) coexistem para a mesma entrada.
- Atributo versus elemento filho: escalares tornam-se conteúdo de texto por padrão; objetos de conjunto de atributos aninhados (valores apenas escalares) tornam-se atributos prefixados com @ (BadgerFish). JSONML usa chaves 'tag' / 'attr'. oData / Atom usa elementos wrapper.
- Arrays: o padrão da página repete elementos filhos (convenção OOXML/SOAP). Alternativas: envolver em um elemento contêiner ou codificar como uma string delimitada. A ordenação do array JSON é preservada na saída XML.
- Regras de nomes de elementos XML: devem começar com uma letra, sublinhado ou dois-pontos, seguido de letras/dígitos/hífens/sublinhados/pontos/dois-pontos (XML 1.0 §2.3). Chaves JSON como '123' ou 'first name' são nomes XML inválidos e devem ser slugificadas ou rejeitadas.
- Escape de entidades: `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`, qualquer outro caractere de codificação como `&#xHHHH;`. As 5 entidades embutidas são obrigatórias; extras do HTML como ` ` precisam de um DOCTYPE explícito.
- Prólogo do documento: `<?xml version="1.0" encoding="UTF-8"?>` é a primeira linha padrão. Declarações xmlns no elemento raiz declaram prefixos de namespace; JSON não possui conceito de namespace, então o conversor escolhe por projeto.
- JSON null → XML: `<key xsi:nil="true"/>` (convenção XML Schema) ou `<key></key>` (elemento vazio). A escolha deve corresponder ao XSD do consumidor, caso contrário a validação falha.
- A direção inversa XML → JSON possui as mesmas ambiguidades: seções CDATA tornam-se chaves `$` ou `#text` (BadgerFish), elementos de conteúdo misto (texto + elementos filhos intercalados) não possuem forma JSON limpa e geralmente são concatenados em uma string.
Exemplos
Objeto -> Elemento
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>Array -> Elementos
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>Estrutura aninhada
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>Perguntas frequentes
Como o conversor mapeia JSON para XML?
Cada objeto JSON vira um elemento XML. As chaves do objeto viram nomes de elementos filhos; valores primitivos viram o texto do elemento. Arrays repetem o elemento pai várias vezes. Caracteres especiais no texto são escapados (& → &, < → <).
Por que JSON-para-XML nem sempre é sem perdas?
O JSON tem tipos explícitos para number/boolean/null; o XML só tem texto. JSON permite chaves com espaços ou caracteres especiais; nomes de elementos XML não. Arrays no nível raiz não têm equivalente óbvio em XML. A página usa heurísticas (elemento envolvente 'root', chaves inválidas sanitizadas) para preencher essas lacunas.
Como valores de array são representados em XML?
Cada elemento do array vira um elemento irmão com o mesmo nome. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. O envolvimento é configurável; algumas páginas permitem escolher explicitamente o nome do elemento singular.
E as chaves JSON que não são nomes XML válidos?
Nomes de elementos XML não podem começar com dígito, conter espaços ou incluir certos símbolos. A página sanitiza substituindo caracteres inválidos por sublinhados ou envolvendo em CDATA. O resultado é XML válido, mas o round-trip não é exato.
null e boolean do JSON são preservados?
null vira um elemento vazio ou é omitido, dependendo das configurações. true/false viram o texto literal 'true' ou 'false'. Não há padrão XML para esses tipos — parsers downstream precisam aplicar sua própria interpretação de tipo.
Posso adicionar atributos XML?
JSON não tem o conceito de atributo, então o gerador emite tudo como elementos por padrão. Alguns conversores usam um prefixo de chave especial (por exemplo, '@id') para indicar atributos — confira as opções da página se a saída de atributos for importante para seu schema XML.
A conversão é local?
Sim. O parse de JSON e a geração de XML acontecem no seu navegador. As entradas não são enviadas para nenhum servidor.