Sin subida, 100% local, sin cuenta

Artículo

Comparar fragmentos de código sin subirlos

Cada vez que pegas dos archivos en una herramienta de diff en línea, ese código abandona tu máquina. Archivos de configuración, consultas de base de datos, claves de API enterradas en un fragmento .env: todo viaja a un servidor que no controlas. Este artículo explica cómo funcionan los algoritmos de diff, qué significan en la práctica las opciones de granularidad y por qué mantener la comparación en local es importante.

Qué calcula un diff

Una herramienta de diff toma dos textos y encuentra el conjunto mínimo de cambios que convierte uno en el otro. La idea central es la subsecuencia común más larga, o LCS: la secuencia más larga de líneas (o tokens) que aparece en ambos textos en el mismo orden, aunque no sean adyacentes. Todo lo que no está en esa subsecuencia común es una adición en la nueva versión o una eliminación de la antigua. El algoritmo clásico para esto es el de Myers (1986), que encuentra el script de edición más corto en tiempo O((N+M)D), donde N y M son las longitudes de los dos textos y D es el número de ediciones. En la práctica, la mayoría de las herramientas añaden un paso de preprocesamiento para ignorar las líneas comunes iniciales y finales, reduciendo el problema a la región modificada. El resultado es un parche: una secuencia de bloques, cada uno describiendo un bloque contiguo de líneas de contexto, eliminaciones y adiciones. Este es el formato usado por el diff de Unix, Git y la mayoría de herramientas de revisión de código.

Diagrama que muestra dos entradas de texto alineadas por su subsecuencia común más larga, con líneas coincidentes conectadas y líneas diferentes marcadas como adiciones o eliminaciones

Granularidad de línea, palabra y carácter

La granularidad de un diff determina qué cuenta como unidad de comparación. El diff por líneas es el predeterminado en la mayoría de herramientas: cada línea se trata como un único token. Es rápido y produce una salida fácil de leer en contexto, pero marca una línea entera como modificada aunque solo haya cambiado una palabra. El diff por palabras divide cada línea en palabras antes de ejecutar LCS. Esto ofrece una imagen más precisa de lo que cambió dentro de una línea, lo que resulta útil para prosa, valores de configuración o JSON. El diff por caracteres va más allá y puede resaltar una sola letra modificada dentro de un identificador largo. El manejo de espacios en blanco añade ruido. Una línea que termina en CRLF y la misma línea que termina en LF aparecerán como diferentes bajo una comparación byte a byte estricta. La mayoría de las herramientas ofrecen una opción para normalizar los finales de línea antes de comparar. Del mismo modo, los espacios finales, la sangría con tabuladores frente a espacios y las líneas en blanco pueden generar salidas de diff irrelevantes. Activar la normalización de espacios en blanco suele ser el valor predeterminado correcto al comparar código de diferentes editores o sistemas operativos.

El riesgo para la privacidad de las herramientas de diff en línea

Los servicios de diff y pastebin en línea son cómodos: abre una URL, pega dos fragmentos, obtén una salida coloreada. El problema es que el texto que pegas se transmite a un servidor de terceros. Según el servicio, ese texto puede registrarse, indexarse, almacenarse indefinidamente o compartirse con proveedores de analítica. Esto importa especialmente cuando el código contiene material sensible. Credenciales codificadas en el código, nombres de host internos, lógica de negocio propietaria o datos de identificación personal pueden acabar en un pegado. Incluso sin secretos explícitos, la estructura del código interno puede revelar decisiones de arquitectura que preferirías mantener privadas. El riesgo no es hipotético. Investigadores de seguridad han encontrado repetidamente credenciales y tokens internos en pegados públicos. Algunos servicios conservan los pegados incluso después de que el usuario los elimina, porque existen copias en cachés o copias de seguridad. No hay forma de verificar qué hace un servicio remoto con el texto una vez que llega. La única mitigación fiable es mantener el diff en local, lo que significa ejecutarlo en una herramienta que nunca envíe el texto por la red.

Captura de pantalla de un panel de red del navegador que muestra cero solicitudes salientes mientras se comparan dos fragmentos de código en la herramienta text-diff

Usos prácticos de un diff local

El diff no es solo para la revisión de código. Algunos casos comunes en los que un diff local resulta útil: Revisar ediciones en un documento o archivo de configuración antes de hacer commit. Comparar dos versiones de un Dockerfile, una configuración de Nginx o un manifiesto de Kubernetes para entender exactamente qué cambió entre despliegues. Comprobar la deriva de configuración entre entornos. Si se supone que las configuraciones de producción y staging son idénticas salvo por los nombres de host y los secretos, un diff muestra de inmediato cualquier divergencia no deseada. Comparar respuestas de API durante la depuración. Pegar dos cargas JSON de una API REST o GraphQL y ejecutar un diff por palabras identifica campos añadidos, valores modificados o claves eliminadas sin leer cientos de líneas manualmente. Revisar código generado por LLM frente a una línea base. Cuando un modelo reescribe una función, un diff por líneas muestra qué lógica cambió y cuál se mantuvo, más rápido que leer ambas versiones de forma independiente. En todos estos casos, el texto puede ser sensible, y mantenerlo fuera de un servidor remoto es la opción directa.

Hacerlo en el navegador, sin subir nada

La herramienta text-diff de este sitio ejecuta todo el cálculo del diff en tu navegador mediante JavaScript. Pegas dos textos en los dos paneles y el diff se renderiza de inmediato, línea por línea, hasta 3000 líneas por lado. No se envía nada a un servidor. El texto nunca sale de tu dispositivo. La implementación usa un algoritmo estándar basado en LCS que opera sobre líneas: cada línea es un token, y la herramienta determina si está sin cambios, añadida o eliminada buscando la subsecuencia común más larga entre las dos versiones. Las líneas sin cambios se muestran sin resaltado, las añadidas en verde, las eliminadas en rojo, junto a un recuento en vivo de adiciones y eliminaciones. Hoy no hay modo de palabra ni de carácter, ni un interruptor de normalización de espacios en blanco, así que una línea que solo difiere en espacios finales o en el estilo de fin de línea se sigue mostrando como cambiada. Como el cálculo se ejecuta en el lado del cliente, funciona sin conexión. No hay cuenta, ni historial, ni retención. Puedes comparar un archivo de configuración local con una plantilla, revisar un parche antes de aplicarlo, o comprobar dos respuestas de API sin que ninguno de esos textos llegue a un tercero.

Herramientas en este artículo

Preguntas frecuentes

¿Es mejor el diff por líneas o por palabras para el código?

El diff por palabras puede ayudar cuando las líneas son largas y solo ha cambiado una pequeña parte, como en un valor JSON de una sola línea, pero esta herramienta compara solo a nivel de línea; en ese caso, usa la línea resaltada como referencia y localiza a simple vista la diferencia menor dentro de ella.

¿Por qué las herramientas de diff en línea suponen un riesgo para la privacidad aunque usen HTTPS?

HTTPS protege el texto en tránsito frente a escuchas, pero no lo protege una vez que llega al servidor. El operador del servicio tiene acceso completo al contenido pegado y puede registrarlo, almacenarlo o compartirlo. TLS es sobre seguridad en el transporte, no sobre lo que el destinatario hace con los datos.

¿La herramienta text-diff guarda algún historial de comparaciones anteriores?

No. La herramienta no tiene backend y no realiza solicitudes de red. Una vez que cierras o recargas la pestaña, el texto desaparece. No hay cuenta, ni historial guardado, ni registro en el servidor.