Original
Modificado
Comparar Textos Online — Diff Checker para Encontrar Diferencias
Suelta dos versiones de cualquier texto — un párrafo que reescribiste, un fichero de config antes y después de un cambio, dos snippets de log pegados, dos borradores de un email — y la página pinta las adiciones en verde, las eliminaciones en rojo y las líneas idénticas en gris apagado. La comparación es un diff real Longest Common Subsequence (LCS), el mismo algoritmo que mueve `git diff` y `diff(1)` de Unix, así que cuando insertas una línea arriba todo lo de debajo se queda como "igual" en vez de cascadar en un par fake de remove/add como hacen herramientas más simples. Útil para code review, redlines de contratos, comparar prompts que afinaste entre runs de LLM, revisión A/B de copy o auditar qué cambió en un YAML/INI/.env entre dos backups.
Sobre esta herramienta
El diff es un algoritmo LCS de programación dinámica con tiempo y memoria O(n·m) — para dos entradas de longitud n y m la página reserva una tabla `Int32Array((n+1)×(m+1))` para computar la subsecuencia común más larga, y luego hace back-trace para emitir adiciones, eliminaciones y líneas compartidas. La memoria está limitada a 4 millones de celdas (~16 MB) — entradas mayores auto-recurren a una comparación naive línea por línea para que la página se mantenga responsive en vez de reservar gigas. El camino LCS siempre toma el paso diagonal ("igual") cuando ambas líneas coinciden, y si no prefiere el mayor de (arriba, izquierda) — esto coincide con la variante estándar Hirschberg/Hunt-Szymanski a la que convergen la mayoría de herramientas de diff. La salida preserva el orden original de líneas y surface los movimientos correctamente: borrar la línea 5 y añadir la misma línea como línea 8 se muestra como un remove + un add lejos entre sí, no como ocho líneas de churn. Casos de uso: revisión de pull-request cuando quieres un diff rápido sin git, comparar dos párrafos de un artículo, encontrar qué cambió en un fichero de config que respaldaste antes de un deploy, redlinear un texto legal o revisar dos respuestas del mismo prompt de LLM para detectar drift.
- Diff LCS real — misma clase de algoritmo que git diff / Unix diff
- Detecta inserciones y movimientos correctamente (sin cascadas fake)
- Salida con código de colores: verde añadido, rojo eliminado, gris apagado igual
- Memoria limitada a 4M celdas; auto-fallback a diff naive sobre el límite
- Reactivo — re-diff mientras editas cualquier panel
- Entrada textarea lado a lado en escritorio, apilada en móvil
- Procesa comparaciones de 2.000×2.000 líneas en milisegundos dentro del límite LCS
- Las líneas vacías se diffan correctamente (importan para el orden)
- Sin subida — ambos textos y el diff se quedan en tu navegador
- Útil para code review, redlines de contratos, auditorías de config, drift de LLM
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Qué es LCS y por qué produce mejores diffs que la comparación línea-por-línea?
Un Longest Common Subsequence (LCS, subsecuencia común más larga) es la secuencia más larga de líneas que aparecen en el mismo orden en ambas entradas (no necesariamente contiguas). Hunt y Szymanski (1977, CACM 20(5):350–353) dieron el primer algoritmo LCS rápido; Hirschberg (1975, CACM 18(6):341–343) demostró que puede computarse en espacio lineal; Myers (1986, Algorithmica 1:251–266) dio el algoritmo O(ND) que potencia git diff (por defecto) y GNU diffutils (variante heurística por defecto). El planteamiento LCS es '¿cuál es el conjunto más grande de líneas que podemos alinear entre la entrada A y la entrada B?', y el diff es entonces 'todo lo que está en A pero no en el LCS = eliminado; todo lo que está en B pero no en el LCS = añadido; todo lo que está en el LCS = igual'. El diff ingenuo línea-por-línea (comparar línea 1 de A contra línea 1 de B, etc.) maneja mal las inserciones y eliminaciones: una sola línea añadida al inicio de B se propaga en N pares quitar/añadir para todo lo de abajo.
¿Por qué la herramienta cae a comparación naive por encima de 4M celdas?
La tabla LCS de programación dinámica es un Int32Array de tamaño (n+1)×(m+1) donde n y m son los recuentos de línea de la entrada A y B. A 4 millones de celdas el array usa unos 16 MB de memoria; para dos entradas de 2.000 líneas ese es el límite. Por encima del cap, asignar gigabytes de memoria colapsaría la página o ralentizaría el navegador hasta detenerlo. El respaldo es una comparación rápida línea-por-línea: recorrer ambas entradas en paralelo, marcando las líneas que difieren en la misma posición. No es tan precisa como LCS — una sola línea insertada se propaga en N diferencias debajo — pero permite que la página siga respondiendo con entradas muy grandes en lugar de morir.
¿En qué se diferencia el algoritmo O(ND) de Myers de Hunt-Szymanski?
Hunt y Szymanski (1977) computan LCS en tiempo O((r+n) log n) donde r es el número de 'pares ordenados de posiciones coincidentes' entre A y B — rápido cuando las coincidencias son escasas, lento cuando son densas. Myers (1986) reformuló LCS como un problema de camino más corto en grafos y dio un algoritmo O(ND) donde N es la longitud de entrada y D es el tamaño del diff resultante; para diffs típicos de control de versiones donde la mayoría de líneas están sin cambios (D es pequeño), Myers es drásticamente más rápido. Hirschberg (1975) es una optimización distinta: aplicada a la recurrencia estándar de programación dinámica O(nm), su construcción divide y vencerás reduce el espacio auxiliar de O(nm) a O(n+m) a costa de un factor de tiempo aproximadamente 2× — así el mismo algoritmo LCS puede correr sobre entradas mucho más grandes sin el blowup de memoria. La implementación de esta página usa la programación dinámica cuadrática directa porque produce scripts de edición (añadido/eliminado/igual) que coinciden con la salida estilo git diff; Myers y Hirschberg son optimizaciones prácticas encima, no semánticas de salida diferentes.
¿Por qué insertar una línea al inicio de la entrada B no se propaga como quitar/añadir para el resto?
Porque el algoritmo LCS encuentra primero la subsecuencia común más larga, y luego deriva el diff de ella. Si la entrada A es `[a, b, c, d]` y la entrada B es `[x, a, b, c, d]`, el LCS es `[a, b, c, d]` — toda línea de A aparece en B en el mismo orden. El resultado del diff es 'B tiene una línea extra (x) al inicio' y las cuatro líneas siguientes se marcan 'igual' en ambos lados. El diff ingenuo línea-por-línea compararía A[0]=a contra B[0]=x (distinto), A[1]=b contra B[1]=a (distinto), y así sucesivamente — cada línea se propaga en un cambio falso. Esta es la razón práctica por la que git diff y Unix diff(1) usan LCS en lugar de comparación ingenua: los parches se mantienen mínimos y legibles incluso cuando el contenido está reordenado.
¿Cómo maneja esta herramienta la accesibilidad para lectores de pantalla?
La región de resultado del diff está marcada con aria-live="polite", el patrón del Criterio de Éxito 4.1.3 de WCAG (Mensajes de Estado, introducido en WCAG 2.1, recomendación del W3C del 5 de junio de 2018; trasladado sin cambios a WCAG 2.2, recomendación del 5 de octubre de 2023). Las regiones live polite encolan anuncios tras cualquier habla en progreso, así que editar cualquiera de los paneles de entrada anuncia el nuevo resultado del diff sin interrumpir al usuario a mitad de frase. Los lectores de pantalla (NVDA, JAWS, VoiceOver) consumen la región live automáticamente; el usuario no necesita hacer nada más.
Fuentes (5)
- Myers, E. W. (1986). An O(ND) Difference Algorithm and Its Variations. Algorithmica, 1, 251–266 (DOI 10.1007/BF01840446) — the algorithm powering git diff and GNU diff.
- Hunt, J. W., & Szymanski, T. G. (1977). A Fast Algorithm for Computing Longest Common Subsequences. Communications of the ACM, 20(5), 350–353 (DOI 10.1145/359581.359603).
- Hirschberg, D. S. (1975). A Linear Space Algorithm for Computing Maximal Common Subsequences. Communications of the ACM, 18(6), 341–343 (DOI 10.1145/360825.360861).
- ECMA International (2025). ECMAScript 2025 Language Specification — Int32Array typed array. ECMA-262, 16th edition, June 2025.
- World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).
Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.
Por Marco B. ·