Por qué no deberías pegar JSON sensible en herramientas online

Un desarrollador se topa con un error de parseo, copia el JSON de la respuesta de la API, y lo pega en el primer formateador online que aparece en Google. El JSON contiene IDs de usuario, direcciones de correo, tokens de sesión o un archivo de configuración interno. Esto pasa decenas de veces al día en todos los equipos de ingeniería. Este artículo explica exactamente qué riesgos crea —— y por qué una herramienta nativa del navegador los elimina.

Qué tipo de datos acaban en herramientas JSON online

En la práctica, los desarrolladores pegan lo que sea que esté causando el problema inmediato. Eso significa:

• Tokens JWT —— contienen claims de identidad de usuario, roles y expiración. La firma evita la manipulación, pero el payload es texto plano codificado en Base64url: cualquiera que loguee tu token puede leer cada campo.
• Respuestas de API con PII —— nombres, correos, teléfonos, fechas de nacimiento, direcciones. Una sola página de resultados de búsqueda de una API de cara al cliente puede contener cientos de registros.
• Archivos de configuración —— strings de conexión a base de datos, API keys de terceros, ajustes de feature flags, URLs de servicios internos.
• Exports de base de datos —— dumps JSON de tablas enteras, a veces generados para depurar y pegados tal cual.
• Datos de negocio internos —— reglas de precios, términos de contrato, datos de productos no liberados que no tienen clasificación pública pero siguen siendo sensibles.

Nada de esto se siente sensible en el momento. El desarrollador quiere entender la estructura, no compartir datos. Pero el acto de pegarlo en una herramienta online es indistinguible de enviárselo a un tercero.

Qué pasa cuando envías datos a una herramienta online

La mayoría de los formateadores, validadores y herramientas de diff online funcionan enviando tu entrada a un endpoint del servidor, procesándola allí y devolviendo el resultado. Incluso herramientas que afirman ser «client-side» a veces envían datos para logging, analytics o tracking de errores. Esto es lo que le puede pasar a los datos por ese camino.

Logging del lado servidor

Los servidores web loguean los bodies de petición por defecto en muchos frameworks. Un solo POST de tu payload JSON puede acabar en:

• Logs de aplicación guardados en disco o en un servicio de logging (Datadog, Splunk, CloudWatch)
• Herramientas de tracking de errores (Sentry, Bugsnag) —— especialmente si falla el parseo
• Una fila de base de datos en una tabla de «analytics» o «usage»
• Logs de acceso de CDN o load balancer que el operador de la herramienta ni siquiera monitorea

Las políticas de retención de logs varían mucho. Algunas herramientas mantienen logs 90 días; otras los mantienen indefinidamente. En cualquier caso, el operador —— y cualquiera que acceda a sus sistemas —— puede leer lo que enviaste.

Analytics de terceros

Muchas herramientas online incluyen JavaScript de terceros para analytics o publicidad. Estos scripts pueden observar peticiones de red, envíos de formularios y eventos de input. Si una herramienta envía tus datos a su propio servidor, la capa de analytics también puede ver la transacción HTTP.

Caché y almacenamiento en CDN

Algunas herramientas cachean resultados por contenido de entrada. Si dos usuarios envían el mismo JSON, el segundo obtiene una respuesta cacheada. La entrada puede quedarse en la caché horas o días. En casos patológicos, cachés mal configuradas han hecho que envíos de usuarios fueran públicamente accesibles vía una URL predecible.

Indexación por motores de búsqueda

Los formateadores que generan un permalink compartible (una URL que contiene o referencia tu JSON formateado) históricamente han visto cómo su salida era rastreada por motores de búsqueda. Buscar un string distintivo de un archivo de configuración interno y encontrarlo en el dominio de un formateador JSON es una experiencia incómoda.

Exposición regulatoria

Si tu organización procesa datos personales bajo GDPR, HIPAA, CCPA o marcos similares, pegar los datos de un usuario en una herramienta online de terceros puede constituir una transferencia de datos no autorizada —— incluso si fue accidental y la herramienta tiene buena reputación. El marco no distingue entre compartir intencionadamente y elecciones descuidadas de herramientas. La pregunta que hace es: ¿salieron datos personales del límite de procesamiento autorizado?

Para entidades cubiertas por HIPAA específicamente, enviar información de salud protegida a un servicio de terceros que no haya firmado un Business Associate Agreement (BAA) es una brecha reportable independientemente de si los datos se usaron mal.

Cómo funcionan distinto las herramientas nativas del navegador

Los navegadores modernos son capaces de ejecutar lógica compleja —— parseo, validación, diffing, formateo, encoding —— totalmente dentro del motor de JavaScript, sin necesidad de petición de red. Una herramienta construida con este modelo se comporta como una aplicación local que casualmente se entrega vía web.

Cuando pegas JSON en una herramienta nativa del navegador:

• El texto entra en una variable JavaScript en la memoria de tu navegador.
• Un parser (también JavaScript) lo procesa en la misma pestaña.
• La salida se renderiza en el DOM.
• No se hace ninguna petición HTTP a ningún servidor con tus datos como payload.

Los datos nunca dejan tu máquina. No pueden ser logueados, cacheados ni indexados porque nunca se transmitieron.

Cómo verificar que una herramienta es realmente local

Afirmaciones como «nunca guardamos tus datos» son comunes e inverificables desde fuera. La única comprobación fiable es el panel Network de tu navegador:

1. Abre DevTools (F12 o Cmd+Option+I).
2. Ve a la pestaña Network y marca Preserve log.
3. Pega tu JSON en la herramienta y dispara la operación (formatear, validar, etc.).
4. Filtra las peticiones por XHR/Fetch. Si alguna petición saliente lleva tu entrada como payload, la herramienta no es client-side.

Una herramienta genuinamente local no mostrará ningún POST o fetch saliente que lleve tus datos. Puedes ver peticiones a assets estáticos (CSS, JS) o pings de analytics, pero ninguno contendrá tu payload JSON.

// Lo que hace una herramienta local —— sin llamada de red:
const result = JSON.parse(userInput);   // se ejecuta en el navegador
render(result);                         // actualiza el DOM

// Lo que hace una herramienta del lado servidor:
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // tus datos salen de la máquina
});

Patrones prácticos: BAAs, WebCrypto y helpers de redacción

Tres patrones cierran la mayor parte del riesgo restante:

• Business Associate Agreements (BAAs) para trabajo cercano a HIPAA —— si tu equipo maneja información de salud protegida, cualquier servicio de terceros que la toque necesita un BAA firmado en el expediente. Por eso pegar PHI en un formateador cualquiera, incluso uno que «corre local», es tanto un problema de documentación como técnico.
• WebCrypto del lado cliente —— cuando realmente necesitas hashear, firmar, cifrar o generar claves en el navegador, la API estándar crypto.subtle lo hace sin un round-trip al servidor. Es la primitiva correcta para «descifra este payload para mirarlo» sin enviar el ciphertext a ningún lado.
• Helpers de redacción —— para depurar, pasa el JSON por un pequeño redactor primero que enmascare los valores en keys conocidas como sensibles (password, token, email, ssn) antes de pegarlo en cualquier lado. Una función de veinte líneas vence a descubrir tokens en el log de peticiones de una herramienta de analytics.

Políticas de equipo que vale la pena tener

La conciencia individual solo llega hasta cierto punto. Una política ligera cubre el hueco:

• Clasifica antes de pegar. Si el JSON contiene nombres, correos, IDs, tokens o claves —— es sensible. Usa una herramienta local o una interna aprobada.
• Mantén una lista de herramientas aprobadas. Una lista corta de herramientas verificadas como local-first es más fácil de seguir que una regla genérica de «ten cuidado».
• Nunca compartas credenciales de producción en sesiones de debug. Rota cualquier token o clave que se haya pegado en una herramienta online, incluso si la herramienta parece segura.
• Usa muestras saneadas para depurar. Reemplaza los valores de usuarios reales por datos sintéticos antes de pegar. Una estructura con "email": "test@example.com" es igual de útil para depurar un error de parseo que la dirección real.

Preguntas frecuentes

¿Es seguro pegar JSON sensible en herramientas online?

Solo si la herramienta procesa todo en tu navegador. Los formateadores del lado servidor pueden loguear, cachear o indexar tu entrada —— y pegar PII en un tercero puede en sí mismo violar GDPR o HIPAA, independientemente de la intención.

¿Cómo verifico si una herramienta JSON corre localmente?

Abre DevTools → Network, marca «Preserve log» y ejecuta la operación. Si ninguna petición saliente lleva tu entrada como payload, la herramienta es client-side. Las peticiones a assets estáticos y de analytics están bien; un POST de tu JSON no.

¿Qué hago si ya pegué un token en una herramienta online?

Rótalo. Trata cualquier credencial o clave que haya tocado una herramienta de terceros como comprometida, incluso si la herramienta parece reputable. Recuerda que un token codificado en Base64 sigue siendo texto plano.

¿Cómo puede mi equipo evitar esto por completo?

Usen herramientas nativas del navegador, mantengan una lista de herramientas aprobadas y depuren con datos de muestra saneados ("email": "test@example.com") en lugar de registros reales.

Qué hace fixjson.org

Cada herramienta de fixjson.org —— reparación de JSON, JSON diff, formateador YAML, JSON Stringify, codificación/decodificación Base64 y decodificación URL —— corre enteramente en tu navegador. El parser, el motor de diff y los formateadores son todos JavaScript ejecutándose localmente. Puedes verificarlo en la pestaña Network: ninguna petición POST lleva tu entrada.

El sitio carga assets estáticos (HTML, CSS, JS) una vez desde un CDN. Después de eso, funciona offline. Ninguna entrada se envía a ningún servidor. Ningún dato se loguea, almacena ni comparte.

• JSON Fix —— repara y formatea JSON inválido, client-side
• JSON Diff —— compara dos documentos JSON o YAML, client-side
• Codificar & Decodificar Base64 —— inspecciona payloads JWT y data URIs sin enviarlos a ningún lado
• URL Decode —— decodifica percent strings de query localmente
• Base64 no es cifrado —— por qué los datos codificados siguen siendo legibles por cualquiera que obtenga el string