Valida contra XML Schema (XSD) ou DTD?

Não — só well-formedness (tags fechadas, aninhamento correto, raiz única). Um XML pode passar aqui e ainda ser rejeitado por um schema específico.

Meus dados são enviados para algum servidor?

Não, todo o parsing roda no navegador. Seguro para colar configs internas ou payloads de API.

Como funciona o parser por baixo dos panos?

É um parser próprio em JS (não usa DOMParser), stack-based: percorre as tags, empilha aberturas e desempilha nos fechamentos, verificando nome e aspas de atributos. Comentários e CDATA são ignorados no processo.

Meu XML passa aqui mas a SEFAZ recusa. Por quê?

Porque são verificações diferentes. Aqui se confere a sintaxe; a SEFAZ confere o layout — tags obrigatórias, ordem, tipos e regras de negócio definidas no schema da NF-e. Um documento pode ser sintaticamente perfeito e ainda assim não cumprir o contrato do destinatário.

O validador é vulnerável a XXE?

Não. O parser usado aqui apenas percorre a estrutura das tags e não resolve entidades externas, DTDs nem referências a arquivos ou URLs. Além disso, ele roda no seu navegador, sem servidor envolvido.

Por que dá erro logo no primeiro caractere?

Quase sempre há algo antes da declaração <?xml — um byte order mark inserido pelo editor ao salvar em UTF-8, espaços em branco, ou uma página de erro HTML devolvida por um servidor que declarou o conteúdo como XML.

Validador de XML Online e Grátis

Escopo: well-formedness, não validação de schema

Verifica só sintaxe estrutural — tags fechadas/aninhadas corretamente, raiz única, aspas balanceadas em atributos. Não valida contra XSD, DTD ou RelaxNG. Útil como primeiro filtro antes de investigar lógica de negócio ou schema: se o XML já não é well-formed, nem vale a pena seguir adiante.

Erros comuns detectados

Tag aberta sem fechamento correspondente
Tag de fechamento com nome diferente da abertura (aninhamento cruzado)
Mais de um elemento raiz no documento
Aspas não balanceadas em valor de atributo

Casos de uso típicos: configs de build (pom.xml, web.config), feeds RSS/Atom que não abrem no reader, payloads SOAP antes de depurar a lógica do serviço.

Bem formado não é o mesmo que válido

A especificação do XML distingue dois níveis, e confundi-los é a causa mais comum de frustração ao depurar integrações:

Bem formado (well-formed) — o documento obedece às regras sintáticas do XML: uma única raiz, toda tag aberta é fechada, o aninhamento não se cruza, atributos têm valores entre aspas. É o que esta ferramenta verifica.
Válido (valid) — além de bem formado, o documento respeita um contrato que define quais elementos podem existir, em que ordem, com que cardinalidade e de que tipo. Esse contrato vem de um XSD, DTD ou RelaxNG.

Um XML pode passar aqui e ainda assim ser rejeitado pelo destinatário. Um NF-e sintaticamente perfeito é recusado pela SEFAZ se faltar uma tag obrigatória do layout, e um payload SOAP bem formado retorna erro se o tipo de um campo não corresponder ao WSDL. Para essa camada é preciso validar contra o schema específico, o que exige o próprio arquivo de schema.

Os erros que mais aparecem

Na prática, XML malformado quase sempre vem de uma destas origens:

Concatenação de string em vez de serialização. Montar XML com interpolação de texto quebra assim que um valor contém <, & ou aspas. Esses caracteres precisam virar entidades (<, &, ") ou ficar dentro de um bloco CDATA.
Resposta truncada. Timeout, limite de buffer ou conexão interrompida produzem um documento cortado no meio, com tags abertas sem fechamento. O erro aparece sempre no fim do arquivo.
Mensagem de erro dentro do corpo. Um servidor que devolve HTML de erro comContent-Type: text/xml gera um documento que o parser rejeita logo na primeira linha.
BOM ou espaços antes da declaração. Qualquer caractere antes de <?xml invalida o documento — inclusive o byte order mark que alguns editores inserem ao salvar em UTF-8.
Codificação divergente. Um arquivo declarado como UTF-8 mas gravado em ISO-8859-1 quebra no primeiro caractere acentuado.

Namespaces e prefixos

Documentos de integração usam namespaces intensamente — soap:Envelope, xsi:type, ds:Signature em documentos assinados. Do ponto de vista da boa formação, o prefixo faz parte do nome da tag: <ns:item> precisa fechar como </ns:item>, e não como </item>.

Um prefixo usado sem a declaração xmlns: correspondente é um erro de namespace, não de sintaxe — o documento continua bem formado, mas o consumidor vai recusá-lo.

Uma nota sobre segurança

Parsers XML que resolvem entidades externas são vulneráveis a XXE (XML External Entity), um ataque em que o documento declara uma entidade apontando para um arquivo local ou uma URL interna, fazendo o servidor ler ou requisitar o que o atacante quiser. Se você processa XML recebido de terceiros, desabilite a resolução de entidades externas e DTDs no parser.

Esta ferramenta não é afetada: ela usa um parser próprio, escrito em JavaScript, que apenas percorre a estrutura das tags e não resolve entidades, DTDs nem referências externas. Todo o processamento acontece no seu navegador, então dá para colar payloads internos sem que eles saiam da máquina. Para inspecionar a estrutura de um JSON com o mesmo cuidado, use o formatador de JSON.

Validador de XML