Comparar y fusionar texto

Cómo funciona

1. Pega dos textos: introduce el texto original en el panel de la izquierda y el texto revisado en el de la derecha.
2. Consulta las diferencias: las líneas modificadas se resaltan, verde para las adiciones, rojo para las eliminaciones y amarillo para las modificaciones.
3. Revisa el diff: desplázate por los cambios con código de color y copia o captura las partes que necesites.

Breve historia del diff

La comparación de texto moderna nació en Bell Labs. Douglas McIlroy (el mismo McIlroy que inventó las tuberías de Unix) y James W. Hunt escribieron el diff original de Unix a principios de los años 1970; se entregó como parte de la 5.ª Edición de Unix en 1974. El algoritmo se documentó en el Bell Laboratories Computing Science Technical Report n.º 41 (junio de 1976), un informe interno titulado «An Algorithm for Differential File Comparison». El algoritmo de Hunt-McIlroy se construye sobre el problema de la subsecuencia común más larga (LCS), encontrar la secuencia más larga de líneas que aparece, en orden, en ambas entradas, y todo lo que no esté en esa secuencia es una eliminación o una inserción. Una década más tarde, Eugene W. Myers publicó «An O(ND) Difference Algorithm and Its Variations» en Algorithmica, Vol 1 número 2 (1986). Myers replanteó el problema como búsqueda del camino más corto sobre un «grafo de edición» y demostró que podía resolverse en tiempo y espacio O(ND), donde N es el tamaño de la entrada y D es el tamaño del script de edición mínimo. Para entradas típicas, archivos que difieren en pocos lugares, D es pequeño, por lo que el algoritmo es rápido en la práctica. El artículo de Myers se convirtió en la base de una implementación Unix diff más rápida que se ejecutaba de dos a cuatro veces más rápido que su predecesora y producía una salida de mayor calidad. Patience diff (Bram Cohen, 2008) es un refinamiento LCS que prioriza líneas de anclaje únicas, produciendo diffs más legibles alrededor de bloques movidos. El valor por defecto actual en git diff es el algoritmo de histograma en LibXDiff, generalmente considerado más rápido que el Myers básico y produciendo diffs más legibles en presencia de bloques movidos (se convirtió en el predeterminado de Git en 2.11, lanzado el 29 de noviembre de 2016). Los fundamentos matemáticos van aún más profundo: la distancia de Levenshtein (Vladimir Levenshtein, 1965) es el primo a nivel de carácter del problema LCS, y la solución de programación dinámica de Wagner-Fischer (1974) es lo que toda biblioteca de «coincidencia difusa» todavía implementa internamente.

Cómo se renderiza un diff

Hay cuatro convenciones visuales comunes para mostrar un diff. Lado a lado, dos columnas, original a la izquierda, modificado a la derecha, con las líneas correspondientes alineadas. Bueno para comparación de un vistazo; funciona bien en anchos de escritorio pero se vuelve ilegible en viewports móviles estrechos. Diff unificado en línea, una sola columna que muestra líneas eliminadas (típicamente prefijadas con - y coloreadas en rojo), líneas añadidas (+, verde) y líneas de contexto sin cambios (sin prefijo, texto plano). La disposición que git diff usa por defecto. Se adapta bien al móvil pero pierde el paralelismo espacial del lado a lado. Diff a nivel de palabra, destacando solo las palabras que cambiaron dentro de las líneas modificadas. Útil para comparación de prosa donde la mayor parte del texto no cambió pero se editaron frases específicas. Diff a nivel de carácter, destacando cada carácter cambiado individualmente. Útil para cambios muy pequeños (una corrección de errata, una edición de un solo dígito) donde el nivel de palabra destacaría la palabra entera. Las convenciones de color son notablemente consistentes en todo el ecosistema: verde para adiciones, rojo para eliminaciones, amarillo o ámbar para valores cambiados, gris neutro o sin estilo para sin cambios. Esta herramienta usa el estilo unificado en línea con resaltado a nivel de carácter dentro de las líneas modificadas, un híbrido que se adapta bien al móvil mientras preserva la precisión de la comparación a nivel de carácter para ediciones de prosa.

Fusión a tres vías, cuando dos diffs deben combinarse

Un diff a dos vías (esta herramienta) te dice qué cambió entre la versión A y la versión B. Una fusión a tres vías responde a una pregunta más difícil: dado un ancestro común y dos revisiones divergentes, ¿cuál es el resultado combinado que incorpora ambos conjuntos de cambios? Esta es la operación central de todo sistema de control de versiones, cuando dos desarrolladores editan el mismo archivo de forma independiente y uno intenta fusionar su trabajo, el sistema necesita aplicar ambos diffs al original. El algoritmo diff3 formalizado por Khanna, Kunal y Pierce (2007) es la base. La convención del marcador de conflicto de siete caracteres, <<<<<<<, =======, >>>>>>>, que Git inserta en los archivos cuando una fusión automatizada falla, proviene directamente de este linaje. Las herramientas modernas de fusión visual (el editor de fusión de tres paneles de VS Code, por defecto desde 1.69 en junio de 2022; Beyond Compare de Scooter Software, desde 1996; Meld; Kaleidoscope de Black Pixel para macOS) manejan fusiones a tres vías con renderizado lado a lado de las tres versiones más un cuarto panel para el resultado de fusión propuesto. Esta herramienta se centra en la comparación a dos vías, la fusión a tres vías pertenece a un flujo de trabajo real de control de versiones.

Casos de uso comunes

• Revisión de código. Pegar dos versiones de una función o módulo para detectar el cambio rápidamente, especialmente cuando se trabaja fuera de un flujo de Git (un fragmento del correo de un colega, una respuesta de Stack Overflow contra tu código actual).
• Comparación de contratos legales. Los abogados y negociadores de contratos comparan rutinariamente dos versiones de un contrato para ver qué cambió la otra parte. El término legal-tech es comparación «blackline» o «redline»; productos como Draftable se especializan en esto.
• Edición de prosa. Comparar el borrador de un escritor con la revisión de un editor, o dos versiones de un artículo. Control de cambios de Microsoft Word hace esto integrado en el producto; para borradores en texto plano o Markdown, una herramienta de diff es el equivalente.
• Deriva de configuración. Comparar un archivo de configuración en producción con la versión en control de fuente, la brecha es la deriva. Mismo flujo para configuraciones específicas del entorno (dev vs staging vs producción).
• Comparación de logs. Hacer diff de dos archivos de log de diferentes ejecuciones del mismo proceso para encontrar el punto de divergencia.
• Revisión de localización. Los traductores frecuentemente hacen diff de una nueva fuente en inglés contra la versión anterior para identificar exactamente qué es nuevo y necesita traducción.

El ecosistema diff en 2026

Más allá de git diff y Unix diff, varias herramientas de diff especializadas merecen mención. Beyond Compare (Scooter Software, 1996) es la herramienta comercial veterana de comparación de carpetas y archivos, popular entre desarrolladores y profesionales TI para diffing entre máquinas. Meld (open source, basado en GTK) es el predeterminado de GNOME. Kaleidoscope (Black Pixel, macOS) se integra con control de versiones y es la elección de facto para muchos desarrolladores Mac. El editor de diff integrado de VS Code maneja comparaciones a dos y tres vías de forma nativa; el editor de fusión de tres paneles se volvió predeterminado en 1.69 (junio de 2022). Mergely (Wayne Stidolph, 2013, licencia MIT) es el editor canónico de fusión a dos vías basado en navegador construido sobre CodeMirror. jsdiff (Kevin Decker, ~2010) es la biblioteca JavaScript de diff dominante, usada por toda herramienta de diff basada en navegador en la que hayas pegado. diff-match-patch (Neil Fraser en Google, 2006) es la biblioteca alternativa que maneja diffing, coincidencia difusa y generación de parches en una sola API; usada en el historial de revisiones de Google Docs. Diffchecker es el servicio freemium dominante de diff en línea, con todas las funciones pero con privacidad detrás de un paywall (el nivel gratuito envía el texto a su servidor). text-compare.com es el sitio de diff de texto puro en la web más antiguo, UI anticuada pero funcional.

Privacidad: por qué el solo-navegador importa especialmente aquí

Cada diff revela exactamente qué cambió entre dos versiones, y lo que cambió a menudo es más sensible que cualquiera de las versiones por sí sola. Tres escenarios concretos donde esto importa agudamente. Parches de seguridad: hacer diff de una versión vulnerable de una función contra la versión parcheada revela la ubicación y naturaleza precisas de un bug de seguridad, un atacante que encuentre el parche puede crear un exploit para la versión sin parchear (el ataque «patch gap» documentado por Tian et al. en USENIX Security 2017). Pegar un parche de seguridad en una herramienta de diff del lado servidor es esencialmente publicar la vulnerabilidad. Negociación de contratos: hacer diff de dos versiones de un contrato revela exactamente qué cláusulas le importan a cada lado, que es precisamente la información que no quieres que la otra parte (o cualquiera observando la red) tenga durante la negociación. Decisiones editoriales pre-publicación: hacer diff de un manuscrito antes y después de la edición revela lo que un autor y editor decidieron cortar o cambiar, a menudo más revelador que la versión final publicada. Las herramientas de diff del lado servidor suben ambas versiones a un tercero, donde quedan en logs. Esta herramienta se ejecuta enteramente en tu navegador vía JavaScript, verifícalo en la pestaña Red de DevTools mientras haces clic en Comparar, o desconecta la página (modo avión) después de que cargue y la herramienta sigue funcionando.

Preguntas frecuentes

¿Puedo comparar archivos de código?

Sí. Pega cualquier texto, incluido código, JSON, HTML, Markdown o texto plano. El diff es puramente textual, así que funciona para cualquier formato.

¿Ignora las diferencias de espacios?

Activa la opción «Ignorar los espacios» para saltarse las diferencias que solo sean espacios o finales de línea. Útil para comparar código reformateado pero no modificado en el fondo.

¿Qué algoritmo usa esto?

El algoritmo O(ND) de Myers (Eugene Myers, Algorithmica Vol 1 N.º 2, 1986), el mismo algoritmo que GNU diff usó por defecto durante décadas y la base de la mayoría de implementaciones de diff de texto. Myers replanteó el problema de la subsecuencia común más larga como búsqueda de camino más corto sobre un grafo de edición, haciéndolo rápido en la práctica para entradas que difieren en pocos lugares. El algoritmo de histograma más nuevo (predeterminado actual de Git desde v2.11, noviembre de 2016) maneja ligeramente mejor los bloques movidos pero es excesivo para el caso típico de dos pegados que esta herramienta maneja.

¿Hay un límite de tamaño?

Sin límite estricto, pero la comparación se ejecuta en tu navegador vía JavaScript, así que el techo práctico es la memoria disponible de tu dispositivo. Decenas de miles de líneas funcionan cómodamente. Entradas muy grandes (archivos de log de varios MB, novelas completas) se ejecutarán pero pueden tardar segundos notables en renderizarse. Para entradas genuinamente enormes usa el diff de Git en línea de comandos, hace streaming de la salida y maneja archivos de tamaño arbitrario sin presión de memoria.

¿Puede hacer fusión a tres vías o aplicar parches?

Actualmente no, esta herramienta se centra en comparación a dos vías (A vs B). La fusión a tres vías (el algoritmo diff3 con marcadores de conflicto <<<<<<< / ======= / >>>>>>>) es la operación que Git usa al fusionar ramas; requiere un ancestro común más dos versiones divergentes. Para fusión a tres vías, usa un sistema de control de versiones real o una herramienta dedicada como el editor de fusión de tres paneles de VS Code (por defecto desde 1.69 en junio de 2022).

¿Se suben mis textos?

No. La comparación se ejecuta enteramente en tu navegador vía JavaScript. Los textos que pegas nunca cruzan la red, verifícalo en la pestaña Red de DevTools mientras haces clic en Comparar, o desconecta la página (modo avión) después de que cargue y la herramienta sigue funcionando. Especialmente seguro para hacer diff de parches de seguridad (donde el diff mismo revela la vulnerabilidad), revisiones de contrato (donde el diff revela posiciones de negociación) o borradores editoriales pre-publicación.