Conversores JSON online são seguros? Verifique antes de colar segredos

A resposta curta

Um conversor JSON, YAML ou CSV online só é seguro de usar quando você consegue confirmar que sua entrada nunca é enviada para um servidor e nunca é armazenada. Algumas ferramentas online fazem todo o trabalho dentro do seu navegador, então seus dados nunca saem da aba. Outras enviam silenciosamente o que você cola, registram em log e, em alguns casos, publicam. Você não tem como saber qual tipo está usando apenas pela página inicial, então o hábito seguro é verificar antes de colar qualquer coisa sensível.

Este artigo mostra como fazer esse julgamento você mesmo, com um checklist que dá para aplicar a qualquer conversor, um teste no DevTools que leva trinta segundos e as categorias de dados que você nunca deve colar em uma ferramenta web que não verificou.

Orientação rápida:

Dados de amostra públicos e não sensíveis: qualquer formatador respeitável serve.
Qualquer coisa que contenha credenciais, tokens, dados de clientes ou configuração interna: use apenas uma ferramenta que você verificou que roda inteiramente no seu navegador, ou converta offline.
Na dúvida: trate como inseguro e use um método local.

Se você quer um conversor que dá para verificar agora mesmo que roda no navegador, o JSON Formatter do FormatArc continua funcionando com sua rede desativada, porque ele nunca envia sua entrada para lugar nenhum.

Por que essa pergunta importa agora

Em novembro de 2025, a empresa de segurança watchTowr publicou uma pesquisa sobre dois dos sites de formatação e conversão online mais populares, JSONFormatter e CodeBeautify. Ambos ofereciam um recurso de salvar e compartilhar com uma página de "Links recentes". Os links compartilháveis seguiam um padrão de URL previsível, o que significava que qualquer um podia enumerá-los com um crawler simples e ler tudo o que outros usuários haviam salvado.

Os pesquisadores coletaram mais de 80.000 submissões salvas, mais de 5 GB de dados. Lá dentro havia credenciais do Active Directory, chaves de acesso a bancos de dados e nuvem, chaves privadas, segredos de pipelines de CI/CD, tokens JWT e de API, credenciais de gateways de pagamento e exports completos do AWS Secrets Manager. As organizações afetadas abrangiam governo, bancos, saúde, seguros, aeroespacial e telecomunicações. Você pode ler a divulgação completa no relatório da watchTowr.

Um detalhe torna a lição inequívoca. Os pesquisadores enviaram canary tokens configurados para expirar após 24 horas. Eles registraram alguém acessando esses tokens 48 horas após o upload, depois de os links supostamente terem expirado. Atacantes já estavam raspando essas plataformas e testando as credenciais que encontravam.

A conclusão não é que esses dois sites eram excepcionalmente ruins. É que qualquer coisa que você cole em um conversor que armazena ou transmite sua entrada pode ser exposta da mesma forma, por um vazamento, uma configuração errada, uma invasão ou um recurso cuja existência você desconhecia. A solução é usar ferramentas cuja arquitetura torna a exposição impossível, e saber distinguir uma da outra.

Os três modelos de processamento

Conversores online se dividem em três grupos com base no que acontece com seus dados. Essa diferença é a questão inteira.

Modelo	Onde os dados são processados	Armazenado em um servidor	Risco típico
Server-side (upload)	Enviado ao servidor do provedor	Frequentemente, ao menos temporariamente	Alto: trânsito, logs, invasões, retenção
Salvar e compartilhar	Enviado e deliberadamente persistido com uma URL	Sim, por design	O mais alto: links públicos, URLs previsíveis, retenção indefinida
Browser-side (client-side)	Dentro da aba do seu navegador	Não	Baixo: nada é enviado nem armazenado

Um conversor server-side precisa receber seus dados para processá-los. Mesmo um provedor honesto os mantém em trânsito, na memória, possivelmente em logs de acesso e possivelmente em arquivos temporários. Uma única configuração errada expõe tudo isso.

Um modelo de salvar e compartilhar é pior porque armazenar sua entrada é o objetivo do recurso, não um acidente. É exatamente esse o modelo que vazou na pesquisa da watchTowr. A conveniência de "compartilhe este JSON formatado com um link" é o mesmo mecanismo que tornou 80.000 submissões publicamente legíveis.

Um conversor browser-side carrega seu código uma vez e depois faz tudo localmente em JavaScript. Sua entrada nunca atravessa a rede. Não há nada em um servidor para vazar, porque nada nunca foi enviado.

Os verdadeiros culpados: enviar e armazenar

Vale ser preciso sobre o que de fato causa a exposição, porque algumas defesas em que as pessoas confiam não atacam o problema.

Os dados são enviados. Se a ferramenta faz POST da sua entrada para um servidor para processá-la, seus dados saíram do seu controle no momento em que você clicou em converter. O que o provedor faz com eles em seguida fica fora das suas mãos.

Os dados são armazenados. Mesmo uma ferramenta que processa server-side e afirma apagar os dados imediatamente pode manter logs de acesso, logs de erro com payloads ou cópias em cache. Recursos de salvar e compartilhar os armazenam de propósito, às vezes para sempre.

Existe uma URL compartilhável. Se uma ferramenta gera um link para sua saída formatada, essa saída fica em um servidor e é acessível por qualquer um que encontre ou adivinhe a URL. Esquemas de URL previsíveis transformam isso de um risco pequeno em um problema de enumeração em massa.

Os termos de serviço permitem reuso. Algumas ferramentas gratuitas, e muitas baseadas em IA, reservam o direito de usar o conteúdo enviado para analytics ou treinamento de modelos. Uma vez que seu segredo esteja no conjunto de treinamento ou no pipeline de analytics, você não tem como recuperá-lo.

Repare no que não está nesta lista. HTTPS não ajuda aqui. O HTTPS criptografa a conexão entre o seu navegador e o servidor, o que protege contra bisbilhoteiros na rede. Ele não faz nada quanto ao que o servidor faz com seus dados depois que eles chegam: armazenamento, logging, compartilhamento e acesso por operadores acontecem todos do outro lado da criptografia. Uma ferramenta pode ser servida sobre um HTTPS impecável e ainda assim vazar tudo o que você cola.

Como verificar você mesmo que uma ferramenta é browser-side

Esta é a parte que os concorrentes raramente ensinam, e é a habilidade mais útil aqui. Você não precisa confiar em uma política de privacidade. Você pode checar.

Abra o conversor no seu navegador, depois abra o DevTools (F12, ou clique com o botão direito e escolha Inspecionar) e vá para a aba Network (Rede). Agora faça o seguinte:

Clique no dropdown de throttling na aba Network e escolha Offline (ou marque Offline). Isso desconecta a página da rede.
Cole sua entrada e execute a conversão.
Observe o que acontece. Se a ferramenta ainda converte seus dados com a rede offline, o trabalho está acontecendo no seu navegador. Uma ferramenta server-side travaria ou mostraria um erro, porque não consegue alcançar seu backend.

Há uma sutileza que vale conhecer, porque ela separa uma checagem rápida de uma de verdade. Funcionar offline prova que a lógica de conversão é local. Isso não prova, por si só, que a página nunca envia seus dados quando volta a ficar online. Uma página poderia processar localmente e ainda assim fazer POST de uma cópia para algum lugar. Então, para a checagem mais forte, faça o caminho inverso também:

Mantenha a rede online e limpe o log da aba Network.
Cole sua entrada e converta.
Inspecione a lista de requisições. Uma ferramenta genuinamente browser-side não envia nenhuma requisição nova carregando sua entrada. Se você vir um POST ou uma requisição cujo payload contém os dados que você colou, a ferramenta está transmitindo, não importa o que o marketing diga.

Quando você roda esse teste no JSON Formatter do FormatArc, a conversão continua funcionando com a rede offline e não envia nenhuma requisição contendo sua entrada, porque a ferramenta inteira é composta de arquivos estáticos e JavaScript de navegador, sem backend para chamar.

Um checklist de cinco pontos para qualquer conversor

Antes de colar dados sensíveis em uma ferramenta web que você nunca usou, passe por estes pontos. Levam um minuto e fazem a diferença entre seguro e arrependido.

Ela declara explicitamente o processamento client-side? Frases vagas como "seus dados estão seguros conosco" não significam nada. Procure por uma afirmação clara de que o processamento acontece no seu navegador e de que os dados não são enviados a um servidor, e depois verifique.
Ela passa no teste do DevTools? Use as checagens de offline e do log da aba Network acima. Esta é a única afirmação que você pode confirmar em vez de apenas confiar.
Ela tem um recurso de salvar ou compartilhar? Uma página de "salvar isto", "link de compartilhamento" ou "recentes" significa que sua entrada pode ser persistida em um servidor. Esse é exatamente o recurso que vazou no incidente de 2025. Evite-o para qualquer coisa sensível.
Ela está livre de rastreadores e anúncios? Redes de anúncios e scripts de analytics rodam na mesma página dos seus dados. Eles não são o conversor, mas são código de terceiros extra com acesso à página. Menos scripts de terceiros é mais seguro.
Ela funciona offline depois de carregar? Carregue a página, desconecte e confirme que ainda funciona. Uma ferramenta que precisa da rede no meio da conversão está fazendo algo em um servidor.

Veja como comparar ferramentas pelos recursos que importam para a segurança. Preencha para qualquer conversor que você esteja avaliando.

Recurso de segurança	O que procurar
Processamento client-side	A conversão roda no navegador, verificável no DevTools
Sem upload de arquivo obrigatório	Apenas colar, ou leitura local de arquivo que nunca sai da página
Sem URL de salvar ou compartilhar	Sem persistência server-side da sua entrada
Sem rastreadores nem anúncios	Mínimo de scripts de terceiros na página
Funciona offline	Funciona com a rede desativada após o carregamento
Código aberto	O código pode ser inspecionado e auditado por qualquer um

Nenhuma linha sozinha é uma garantia por si só. Uma ferramenta que vai bem em todas elas, e passa no teste do DevTools, é uma em que você pode razoavelmente confiar com entrada sensível.

Browser-side é mais seguro, mas não automaticamente seguro

Seria desonesto afirmar que uma ferramenta browser-side é livre de risco, então aqui vai a nuance. Mesmo quando a conversão acontece localmente, outro código na mesma página ainda pode ver o que você cola:

Redes de anúncios e scripts de analytics rodam na página e podem ler seu conteúdo.
Scripts de terceiros carregados de CDNs externas rodam com as permissões da página.
Extensões de navegador podem ler e modificar qualquer página que você visita, incluindo os dados que você colou.
Uma falha de cross-site scripting (XSS), ou uma dependência comprometida no próprio código da página, pode exfiltrar dados mesmo de uma ferramenta que, fora isso, é local.

É por isso que "menos scripts de terceiros" é uma propriedade de segurança real, não um capricho, e por que código aberto importa: ele permite que o comportamento real da página seja auditado. Um conversor servido como arquivos estáticos, sem analytics, sem rede de anúncios e sem recurso de salvar, tem uma superfície de ataque muito menor do que um abarrotado de rastreadores, ainda que ambos rodem a conversão no navegador. Mantenha seu navegador e suas extensões confiáveis também, já que uma extensão maliciosa derrota toda outra precaução.

Alternativas mais seguras para dados sensíveis

Se você não está confiante de que uma ferramenta web é segura, ou os dados são sensíveis demais para arriscar, você tem boas opções locais.

Ferramentas browser-side verificadas. Um conversor que você confirmou que roda localmente serve até para entrada sensível, porque nada sai da sua máquina. As ferramentas do FormatArc são feitas assim: JSON Formatter, YAML to JSON, JSON to YAML e CSV to JSON rodam todas inteiramente no navegador, sem upload, e continuam funcionando com a rede desativada.

Ferramentas de linha de comando. O jq formata e consulta JSON. O yq converte entre JSON e YAML. Ambos são binários únicos que rodam inteiramente na sua máquina. Para receitas mais aprofundadas, veja Converter JSON para YAML e Converter YAML para JSON, que cobrem em detalhe as abordagens com yq e scripts. Um cuidado: segredos ainda podem ficar no histórico do seu shell, na sua área de transferência e em logs de CI mesmo quando a ferramenta em si é local, então limpe esses rastros se os dados forem realmente sensíveis.

Os recursos nativos do seu editor. O VS Code formata JSON com um atalho de teclado. A maioria dos editores tem formatação de JSON e YAML embutida ou a uma extensão de distância, e eles nunca tocam a rede para isso.

Precisa checar um erro, não converter? Se você só está tentando descobrir por que um parser está rejeitando seu JSON, muitas vezes nem precisa colar o payload real. Reproduza a estrutura com valores de placeholder, ou veja Como corrigir erros de parse de JSON para reconhecer falhas comuns apenas pela mensagem de erro. Quando quiser praticar com algo seguro, use JSON de amostra público e nossas dicas de formatação em vez de dados reais.

Uma nota sobre extensões de navegador: uma extensão de formatação de JSON pode ser conveniente, mas uma extensão lê todas as páginas que você visita e pode ser vendida ou atualizada para se comportar de forma diferente. Se você usar uma, prefira uma opção de código aberto e ativamente mantida, e aplique o mesmo escrutínio. Comparamos opções no guia de extensões JSON para Chrome.

Por que o FormatArc é seguro por construção

O FormatArc é feito de modo que a exposição não seja apenas improvável, mas estruturalmente impossível, e você pode verificar cada afirmação:

100% browser-side. Toda conversão roda em JavaScript dentro da sua aba. Sua entrada nunca é enviada a nenhum servidor.
Sem upload. Você cola seus dados; não há etapa de upload de arquivo que envie seus dados para outro lugar.
Sem backend. O site inteiro é composto de arquivos estáticos em uma CDN. Não há servidor que receba, processe ou armazene sua entrada, então não há nada para vazar, registrar em log ou invadir.
Sem recurso de salvar e compartilhar. Não há página de "links recentes" nem URL compartilhável dos seus dados, que é exatamente o recurso que causou o vazamento de 2025.
Verificável. Desative sua rede no DevTools e as ferramentas continuam funcionando. Observe a aba Network e você não verá nenhuma requisição carregando sua entrada.

Aplique o checklist de cinco pontos acima ao FormatArc e ele passa em todas as linhas que você consegue verificar. O ponto é esse: você não deveria acreditar na nossa palavra, você deveria poder checar, e com uma ferramenta estática browser-side você pode.

Checklist final antes de colar

Os dados são sensíveis (credenciais, tokens, dados de clientes ou pessoais, configuração interna)? Se sim, não os cole em uma ferramenta não verificada.
Você rodou o teste de offline e do log da aba Network no DevTools? Se não, trate a ferramenta como não verificada.
A ferramenta tem um recurso de salvar, compartilhar ou de "recentes"? Se sim, evite-a para dados sensíveis.
Você poderia fazer isso localmente, com uma ferramenta browser-side verificada, com jq/yq ou com seu editor? Se sim, prefira essa via.

Quando a resposta para "consigo confirmar que meus dados nunca são enviados?" é sim, um conversor online é uma ferramenta rápida, conveniente e segura. Quando você não consegue confirmar, presuma o pior e converta offline.

FAQ

Eu já colei um segredo em uma ferramenta online. O que devo fazer?

Trate-o como comprometido. Faça a rotação: gere novamente a chave de API, troque a senha, reemita o token, revogue e reemita o certificado. Presuma que ele já foi raspado, já que a pesquisa da watchTowr mostrou atacantes acessando dados supostamente expirados em até 48 horas. A rotação é a única correção confiável depois que um segredo sai do seu controle.

Minha equipe deveria banir conversores online por completo?

Um banimento geral é difícil de fazer cumprir e empurra as pessoas para ferramentas paralelas. Uma política melhor é permitir ferramentas browser-side verificadas e métodos locais (jq, yq, recursos do editor) para dados sensíveis, e ensinar o teste de verificação no DevTools para que as pessoas possam checar por conta própria. Reserve as ferramentas online não verificadas apenas para dados públicos e não sensíveis.

O HTTPS não é suficiente para manter meus dados seguros?

Não. O HTTPS criptografa a conexão para que ninguém possa bisbilhotar em trânsito. Ele não faz nada quanto ao que o servidor faz com seus dados depois que eles chegam: armazená-los, registrá-los em log, gerar um link compartilhável ou deixar um operador lê-los. Um site com HTTPS impecável ainda pode vazar tudo o que você cola. O que protege você é os dados nunca serem enviados.

Se uma ferramenta funciona offline, ela é definitivamente segura?

Funcionar offline prova que a lógica de conversão roda localmente, o que é necessário, mas não suficiente. Uma página poderia processar localmente e ainda assim enviar uma cópia dos seus dados quando voltasse a ficar online. Para a checagem completa, observe também a aba Network enquanto estiver online e confirme que nenhuma requisição carrega sua entrada. Uma ferramenta que passa nas duas checagens, e não tem recurso de salvar ou compartilhar, é uma em que você pode confiar.

Ferramentas de linha de comando como jq e yq são mais seguras que ferramentas web?

Para a conversão em si, sim: jq e yq rodam inteiramente na sua máquina e não enviam nada. Apenas lembre-se de que segredos ainda podem acabar no histórico do seu shell, na sua área de transferência e em logs de CI, então limpe esses rastros ao lidar com dados realmente sensíveis. Uma ferramenta browser-side verificada oferece segurança semelhante sem nenhuma instalação.