Text Diff en línea: comparar dos textos con LCS/Myers + 6 casos
Una herramienta de text diff online contesta una pregunta muy concreta: ¿qué cambió entre la versión A y la versión B? Pegas dos bloques de texto, la herramienta ejecuta un algoritmo de subsecuencia común más larga (Longest Common Subsequence) y obtienes una vista lado a lado o un diff unificado con cada inserción, eliminación y edición, normalmente en menos de un milisegundo.
Esta guía está pensada para desarrolladores que hacen code review, SRE comparando trozos de logs, abogados marcando cláusulas en contratos y redactores revisando ediciones. Cubre el algoritmo (LCS, Myers, Patience), las dos vistas estándar, las opciones de ignorar que resuelven la mayor parte de las quejas tipo «todo parece haber cambiado», cuándo conviene un JSON diff en su lugar, seis casos prácticos listos para copiar y los problemas frecuentes que el propio algoritmo explica.
¿Quieres ir directo a comparar dos textos ahora? Abre Text Diff: se ejecuta íntegramente en tu navegador, sin subir nada.
1. ¿Qué es un text diff?
Un text diff es el conjunto mínimo de inserciones y eliminaciones que transforma un texto en otro, marcando cada línea como añadida, eliminada o sin cambios. Los diff modernos añaden una segunda pasada a nivel de palabra o carácter, de modo que una edición de un solo carácter resalta únicamente ese token y no la línea entera.
1.1 Por qué la igualdad de caracteres (===) no basta
Inserta una línea al principio de un archivo de configuración de 200 líneas y una comparación ingenua de caracteres reportará como diferente cada byte después del punto de inserción. El texto no cambió: cambió su posición. Un algoritmo de diff tiene que reconocer que «las próximas 199 líneas siguen siendo las mismas, solo desplazadas una posición» y reportar una única inserción. Ese reconocimiento es lo que aporta LCS, y por eso git, GitHub y cualquier herramienta de code review incluyen uno.
1.2 Lado a lado vs diff unificado
La vista lado a lado coloca las dos versiones en columnas paralelas y colorea las celdas: verde para añadido, rojo para eliminado, amarillo para modificado. El diff unificado es el formato de texto más antiguo, proveniente de GNU diff: una columna, marcadores - y +, tres líneas de contexto alrededor de cada hunk. Misma comparación, dos presentaciones. La sección 4 explica cuándo usar cada una.
1.3 Dónde se usa el text diff
Code review en GitHub y GitLab. Salida local de git diff. Parches pegados en Slack. Marcado de contratos. Revisión de traducciones. Snapshot tests de CI que fallan con salida +/-. Investigación de cronologías en logs. Comparación de dos archivos .env. Cualquier escenario donde dos bloques de texto deban alinearse línea a línea.
Abre Text Diff y pega dos textos para verlo en acción; cada comparación corre en local dentro de tu navegador.
2. El algoritmo detrás del text diff (LCS + Myers + Patience)
2.1 Longest Common Subsequence
Dadas dos secuencias de líneas A y B, la Longest Common Subsequence (LCS) es la lista más larga de líneas que aparecen en ambas, en el mismo orden, sin exigir que sean adyacentes. Una vez tienes la LCS, el diff es directo: las líneas que están en A pero no en la LCS se eliminan, las que están en B pero no en la LCS se añaden, y las que sí están en la LCS quedan intactas.
La LCS clásica se calcula con una tabla de programación dinámica de tamaño N × M. La celda (i, j) guarda la longitud de la LCS de las primeras i líneas de A y las primeras j líneas de B. Rellenas la tabla de izquierda a derecha y de arriba abajo, y luego recorres hacia atrás desde la celda inferior derecha para reconstruir el guion de edición. Tiempo y espacio son ambos O(N×M): está bien para dos archivos de mil líneas, lento para un log de cien mil.
2.2 Myers (1986)
El paper de Eugene Myers de 1986, «An O(ND) Difference Algorithm and Its Variations», replantea el problema como el camino más corto en un grafo de edición: los nodos son posiciones (i, j) en las dos entradas, los movimientos horizontales son eliminaciones, los verticales son inserciones y los diagonales son coincidencias. El camino más corto equivale al guion de edición mínimo.
Myers corre en tiempo O((N+M)D), donde D es el tamaño del guion de edición. Cuando los dos textos son parecidos, el caso habitual en un diff, D es pequeño y el algoritmo es prácticamente lineal. Es el predeterminado en git diff, en GNU diff y en el renderizador de PR de GitHub. Para casi todas las entradas web es la respuesta correcta.
2.3 Patience diff (Bram Cohen, 2005)
Patience diff toma otro camino: encuentra las líneas que aparecen exactamente una vez en cada entrada (llamadas «líneas ancla únicas»), las empareja y recurre sobre los huecos entre anclas. La matemática es más sucia (el peor caso sigue siendo malo) pero la salida se lee mucho mejor sobre código.
¿Por qué? Myers minimiza la distancia de edición, lo cual es óptimo matemáticamente pero feo visualmente cuando la alineación óptima atraviesa llaves no relacionadas o líneas en blanco. Patience se niega a alinear sobre boilerplate común (todo archivo tiene líneas }, todo archivo tiene líneas en blanco), así que las fronteras entre funciones se mantienen intactas. Bram Cohen lo inventó para Bazaar; Git lo ofrece como git diff --patience. El algoritmo Histogram, estrechamente relacionado (git diff --histogram), es ligeramente más rápido con calidad de salida similar.
Imagina dos versiones del mismo archivo donde se movió una función. Myers puede alinear la llave de cierre de la función A con la llave de cierre de la función B y reportar los cuerpos como completamente distintos. Patience se ancla sobre los nombres únicos de función y reporta un movimiento limpio. Misma entrada, experiencia de revisión muy diferente.
2.4 Comparación de algoritmos
| Propiedad | Myers (por defecto) | Patience | Histogram |
|---|---|---|---|
| Complejidad temporal | O((N+M)D) | ~O(N log N) en caso común | similar a Patience |
| Distancia de edición óptima | Sí, guion más corto | No, puede ser más largo | No, puede ser más largo |
| Lectura natural sobre código | A veces desalinea llaves y líneas en blanco | Excelente, se ancla en líneas únicas | Excelente |
| Usado por | git por defecto, GNU diff, UI de GitHub | git diff --patience, Bazaar | git diff --histogram |
| Mejor para | Velocidad y corrección en la mayoría de entradas | Code reviews, diffs de refactor | Igual que Patience, algo más rápido |
2.5 Qué hace esta herramienta
Text Diff usa LCS clásica por programación dinámica con dos optimizaciones agresivas: recorte de prefijo y sufijo comunes, y una segunda pasada de LCS a nivel de token para el diff intralínea a nivel de palabra. Un diff de dos configuraciones de dos mil líneas con una sola línea cambiada se reduce a una tabla DP de 1×1 tras el recorte y se renderiza en menos de un milisegundo. Para entradas web típicas la elección entre Myers y DP es invisible: ambos terminan más rápido de lo que el navegador tarda en pintar el resultado.
3. Diff intralínea a nivel de palabra: por qué un cambio de un carácter resalta toda la línea
Cambias un identificador en una línea y la línea entera aparece coloreada en rojo y verde. ¿Un bug? No, está diseñado así.
El diff primero ejecuta LCS al nivel de línea: «la línea 14 fue reemplazada». Después, por cada par reemplazado, ejecuta una segunda LCS al nivel de token. Los tokens se producen partiendo por límites de palabra Unicode: las secuencias de letras y dígitos quedan unidas, los espacios en blanco y los signos de puntuación se convierten en tokens propios. La segunda LCS te da el guion de edición mínimo a nivel de token dentro de esa línea.
El renderizador dibuja la línea completa con el color de resalte para que tu vista la encuentre, y luego pinta solo los tokens cambiados con el fondo brillante. Los tokens sin cambios a su alrededor llevan una versión apagada del mismo color: presentes, pero visualmente discretos. Tu vista aterriza exactamente sobre la edición.
Renombrado de identificador: function getUser(id) pasa a ser function getUser(userId). La línea entera queda marcada como modificada. Dentro de la línea, solo id (tachado en rojo) y userId (verde brillante) llevan el resalte inline. Todo lo demás queda apagado.
Cambio de latencia en logs: POST /api/orders 201 88ms se convierte en POST /api/orders 201 4200ms. La línea está modificada. Inline, solo 88 y 4200 brillan. La ruta, el método y el código de estado se quedan apagados, exactamente lo que necesita quien lee una cronología de incidente.
Cuando cambian demasiados tokens, el resalte a nivel de palabra se vuelve ruido. La herramienta recurre a una presentación en pares de eliminación + adición: la línea original se muestra como eliminada, la nueva como añadida, sin colorear intralínea. El umbral es aproximadamente «más de la mitad de los tokens difieren».
En resumen: el diff de línea te dice qué línea cambió; el diff de palabra te dice qué caracteres de esa línea llevan el cambio. Haz clic en Sample dentro de Text Diff para ver ambas vistas sobre la misma entrada.
4. Lado a lado vs diff unificado: dos vistas, un mismo diff
4.1 Vista lado a lado
Dos columnas: original a la izquierda, modificada a la derecha. Las líneas que coinciden quedan alineadas horizontalmente. Las líneas añadidas aparecen solo en la columna derecha con fondo verde; las eliminadas, solo en la izquierda con fondo rojo; los pares modificados quedan uno al lado del otro con un canalillo amarillo y resalte intralínea a nivel de palabra.
Usa lado a lado cuando un humano vaya a leer el diff: revisión de PR, formación, demos, repaso de un cambio contractual con una persona no técnica. Es la vista para los ojos.
La desventaja: no viaja. No puedes pegar un render lado a lado en Slack y esperar que alguien lo aplique. No puedes pasarlo por una tubería a patch. Para compartir y aplicar necesitas unified.
4.2 Formato de diff unificado
El diff unificado es un formato de texto plano de cincuenta años definido por GNU diff y estandarizado en POSIX. Un ejemplo completo:
--- original
+++ modified
@@ -1,3 +1,4 @@
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
+2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.Las dos primeras líneas nombran los archivos de origen. La línea @@ -L,C +L,C @@ es la cabecera de hunk: -L,C indica que, empezando en la línea L del original, hay C líneas involucradas; +L,C dice lo mismo para la versión modificada. Dentro del hunk, las líneas que empiezan con un espacio son contexto (sin cambios), - es eliminada, + es añadida.
Tres líneas de contexto arriba y abajo de cada cambio es el valor predeterminado de GNU. Casi todas las herramientas permiten cambiarlo con -U n: diff -U0 para sin contexto, diff -U10 para diez líneas. La cabecera de hunk refleja el valor que elijas.
En Text Diff, haz clic en la pestaña Unified para cambiar de vista o en Copy unified diff para llevar el parche al portapapeles.
4.3 Dónde el diff unificado es portable
El diff unificado viaja. Es el formato común para compartir cambios textuales entre herramientas.
| Destino | ¿Acepta diff unificado? | Cómo |
|---|---|---|
GNU patch | Sí | patch -p1 < diff.patch |
git apply | Sí | git apply diff.patch |
| Comentario de revisión de PR en GitHub | Sí (en un bloque ```diff) | Renderiza con color |
| Comentario de MR en GitLab | Sí | Mismo bloque cercado |
| PR en Bitbucket / Azure DevOps | Sí | Mismo bloque cercado |
| Pegar en Slack / Discord | Parcial | Renderiza como texto en bloque de código, sin color |
| «Open Patch» en VS Code | Sí | Aplica parche desde Source Control |
| Cuerpo de issue en Jira / Linear | Parcial | Funciona en bloque de código, sin botón de aplicar |
Las mismas nueve líneas de texto ---/+++/@@ se aplican en patch, en git apply, se renderizan en tres plataformas de PR y sobreviven a un pegado en Slack. Ningún otro formato de diff tiene un alcance ni remotamente parecido.
4.4 Cuándo elegir cada vista
Lado a lado para revisar, unified para compartir y aplicar. Si vas a leer el diff tú mismo, las columnas son más rápidas. Si algo o alguien aguas abajo necesita consumirlo (un revisor, una herramienta, un comando patch), copia el formato unificado.
5. Opciones de ignorar: espacios en blanco, mayúsculas, líneas en blanco, finales de línea
La mayoría de quejas del tipo «todo parece haber cambiado» son ruido. Cuatro interruptores cubren casi todos los casos.
- Ignore case mapea
Aaa. Equivalente agit diff -i. Útil para comparar variables de entorno, auditar el estilo de palabras clave SQL, o cualquier sitio donde la convención sea mayúsculas gritonas frente a minúsculas tranquilas pero el significado sea idéntico. - Ignore all whitespace colapsa todos los espacios, tabulaciones y saltos de línea antes de comparar. Equivalente a
git diff -w. Útil contra el reformateado tabs ↔ spaces, las reescrituras de indentación y los diffs «pasamos a Prettier» que destrozan el conteo de líneas. Un diff con ignore-whitespace sobre esos cambios suele pasar de 87 modificaciones a 4. - Ignore trailing spaces and tabs elimina solo el espacio en blanco al final de cada línea. Equivalente a
git diff -b. Resuelve el ruido CRLF al copiar entre máquinas Windows y Unix: los caracteres\rfinales se filtran y el contenido vuelve a alinearse. - Ignore blank lines descarta las líneas vacías antes del diff. Resuelve el «añadí un salto de párrafo y ahora el párrafo 12 parece completamente distinto» en diffs de prosa.
Una configuración de 200 líneas que reporta «87 modificaciones» suele bajar a «4 modificaciones» tras activar Ignore all whitespace. Una copia de Windows a Unix que marca todas las líneas baja a cero con Ignore trailing spaces. Cada interruptor es independiente y persiste entre sesiones.
CRLF vs LF. En Windows los finales de línea son \r\n; en Unix es \n; en Mac clásico era \r. Abre un archivo de Windows en un editor de Unix que no normalice y conservarás el \r final. Cada línea diferirá como «el contenido coincide pero hay un \r al final». Ignore trailing spaces silencia esto sin perder cambios reales.
Una advertencia. Las opciones de ignorar son un arma de doble filo. Activa Ignore case y un refactor que cambia LOG.error por log.Error parecerá idéntico. Activa Ignore all whitespace y un bug de indentación en Python se vuelve invisible. Elige los interruptores según la pregunta que estés haciéndote, y desactívalos al terminar.
6. Text diff vs JSON diff vs Git diff: matriz de decisión
Text diff es emparejamiento de líneas y palabras sin entender de estructura. Eso es justo lo que quieres para prosa y justo lo que no quieres para JSON.
6.1 Matriz de decisión
| Tipo de entrada | Text diff | JSON diff | Git diff |
|---|---|---|---|
| Prosa / Markdown / contrato | Lo mejor | Herramienta equivocada | Parcial (solo sobre archivos trackeados) |
| Fragmento de código (pegado de un solo archivo) | Lo mejor | Herramienta equivocada | Parcial (necesita un repo) |
| Código en un repo (varios archivos) | Parcial | Herramienta equivocada | Lo mejor |
| Respuesta JSON de una API | Herramienta equivocada (falsos positivos por orden de claves) | Lo mejor | Herramienta equivocada |
| Configuración YAML / TOML | Parcial (falsos positivos por orden de claves) | Lo mejor (tras conversión) | Parcial |
| CSV línea a línea | Parcial | Herramienta equivocada | Herramienta equivocada |
| Log / heredoc | Lo mejor | Herramienta equivocada | Herramienta equivocada |
| Archivo binario | Herramienta equivocada | Herramienta equivocada | git diff --binary |
6.2 Cuándo text diff es la herramienta equivocada
Tres errores típicos.
JSON con claves reordenadas. {"a":1,"b":2} y {"b":2,"a":1} son el mismo documento JSON. Un text diff reportará cada línea como cambiada porque realmente son líneas distintas. Usa Comparar JSON Online, que entiende que las claves de JSON no están ordenadas.
Configuraciones YAML reformateadas. Cambia un valor, pasa el archivo por un formateador y la indentación, el orden de las claves y el entrecomillado cambiarán todos. Un text diff lo reporta como reescritura completa. Convierte ambos archivos a JSON primero y compara con JSON Diff.
Refactors multifichero con renombrados. Git detecta renombrados; text diff no. Si comparas dos árboles concatenando archivos en un solo blob, cada movimiento entre archivos aparece como eliminado + añadido. Usa git diff (o git diff --find-renames=80%) en su lugar.
6.3 Cuándo text diff es exactamente lo correcto
Prosa. Fragmentos de código pegados desde cualquier sitio. Marcado de contratos. Trozos de log. Revisión de traducciones cuando emparejas frases en lenguaje natural. Archivos .env donde el orden importa porque los shells los leen de arriba abajo. Cualquier cosa donde las líneas en sí transporten significado.
Para profundizar en filtrar ruido de los diffs JSON (timestamps, IDs de petición, UUID autogenerados) lee Cómo ignorar timestamps e IDs en JSON Diff.
7. Seis casos reales (con entradas listas para copiar)
7.1 Fragmento para code review: renombrado de función
Estás revisando una PR. El autor renombró id a userId y añadió una cláusula de guarda. Pega ambas versiones:
// Original
function getUser(id) {
const u = db.users.find(x => x.id === id);
return u;
}// Modified
function getUser(userId) {
if (!userId) return null;
const u = db.users.find(x => x.id === userId);
return u;
}El diff muestra tres líneas modificadas y una añadida. El resalte inline a nivel de palabra marca cada token id → userId; la nueva cláusula de guarda aparece con fondo verde. Opciones de ignorar desactivadas. Pruébalo en Text Diff y copia la salida unified para dejarla como comentario de revisión.
7.2 Redline de contrato o política: una cláusula insertada
Cincuenta párrafos de contrato, una cláusula insertada. Pega la versión de ayer a la izquierda y la de hoy a la derecha:
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.El diff muestra cuarenta y nueve líneas sin cambios y una línea añadida (+2a. Termination notice must be in writing.). Exporta el diff unificado como rastro de revisión legal.
7.3 Investigación de cronología en logs
Sospechas una regresión de latencia. Coge un trozo de logs de acceso de antes y durante el incidente:
GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21msGET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21msEl resalte inline saca a flote 88 → 4200 (un salto de latencia de 50×) y 200 → 500 (un endpoint de detalle de pedido empezó a fallar). Para trabajo más rico con logs, como extraer campos, agrupar por endpoint o calcular percentiles, combina el diff con jq Cheat Sheet si tus logs son JSON.
7.4 Revisión de traducciones: preservar placeholders
Contrataste una nueva agencia de traducción y quieres verificar que la nueva copia coincide con la antigua en estructura. Pega la traducción antigua a la izquierda y la nueva a la derecha. Activa Ignore trailing spaces / tabs porque los traductores suelen añadir un espacio extra al final de las cadenas.
El diff confirma que cada placeholder {username}, {count} y %s queda en su sitio; solo cambia el texto en lenguaje natural. Un placeholder ausente aparece como token eliminado en el diff inline, atrapado antes de desplegar. Si necesitas comparar los propios formatos de placeholder, el Cheat Sheet de Regex cubre \{\w+\} y compañía. Pruébalo en Text Diff.
7.5 Auditoría de configuración o .env: producción vs staging
Compara dos archivos .env. Activa Ignore blank lines para que la agrupación en párrafos no desalinee secciones. El diff te muestra qué claves difieren en valor, qué claves existen en un entorno y no en el otro, y dónde se han desincronizado los comentarios. Cinco minutos que evitan la sesión de debugging «funciona en staging pero no en prod».
7.6 Revisión de prosa o borrador
Tu editor te devolvió un borrador. Pega tu original a la izquierda y la versión editada a la derecha. El diff inline a nivel de palabra te muestra exactamente qué frases se reescribieron, cuáles quedaron intactas y qué párrafos se insertaron. Aceptas o rechazas cambios uno a uno, sin función Track Changes, sin archivo Word y sin formato propietario.
8. Errores comunes y cómo leerlos como síntomas
El comportamiento del algoritmo explica la mayor parte del dolor del usuario. Cinco quejas frecuentes y lo que significan en realidad.
Problema 1: «Todas las líneas salen en rojo tras copiar de Windows a Unix». Síntoma: cada línea del diff aparece como cambiada aunque el contenido se ve idéntico. Causa: caracteres \r finales por finales de línea CRLF. Solución: activa Ignore trailing spaces / tabs. El diff caerá hasta los cambios reales.
Problema 2: «Pegué JSON y el 100 % de las líneas son diferentes». Síntoma: dos objetos JSON que deberían ser equivalentes aparecen como completamente cambiados. Causa: claves reordenadas. El text diff toma el orden de líneas como significativo; JSON no. Solución: usa JSON Diff para cualquier entrada JSON.
Problema 3: «Reformatear tabs ↔ spaces hizo explotar el diff». Síntoma: 87 modificaciones, todas de indentación. Causa: tu formateador cambió el espacio en blanco inicial de todas las líneas. Solución: Ignore all whitespace colapsa el ruido y deja a la vista los cambios semánticos reales.
Problema 4: «El diff dice idéntico pero cmp dice que difieren». Síntoma: el diff no reporta diferencias pero una comparación byte a byte dice que los archivos difieren. Causa: una opción de ignorar quedó activada de una sesión anterior y está enmascarando cambios reales. Solución: abre el panel de opciones de ignorar y desactívalo todo, luego vuelve a hacer el diff.
Problema 5: «Una edición corta aparece como eliminar + añadir». Síntoma: un cambio pequeño aparece como una línea eliminada y una añadida separadas, en lugar de un resalte inline. Causa: la proporción de tokens cambiados cruzó el umbral inline y el renderizador cayó al modo de líneas emparejadas. Es diseño, no bug. Cambia a la vista Unified para ver el clásico par -/+ que esperan las herramientas de patch.
9. Privacidad, rendimiento y cuándo recurrir a la línea de comandos
Cada comparación en Text Diff se ejecuta en JavaScript dentro de tu navegador. No hay subida, archivo temporal, log de servidor ni analítica sobre el texto que pegas. Seguro para código propietario, contratos internos, logs privados, cualquier cosa que no estarías dispuesto a pegar en un servidor de terceros.
Límites prácticos: alrededor de 5000 líneas o 1 MB por lado. El diff en vivo se desactiva por encima de 200 KB combinados y se cambia a un botón manual Diff para que escribir no bloquee la página. Por encima de 5000 líneas la entrada se trunca y aparece un aviso. Los límites existen porque el diff corre en el hilo principal (sin web worker), y la transferencia a un worker más la serialización costaría más que el propio diff sobre entradas pequeñas.
Cuando tu entrada supera al navegador, baja a la línea de comandos:
# Unified diff between two files
diff -u a.txt b.txt
# Same, but using git's diff engine (Patience, Histogram, color)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt
# Streaming diff viewer for huge files (Rust, side-by-side, syntax-aware)
delta a.txt b.txtCambia a la línea de comandos para logs de muchos megabytes, archivos binarios, diffs multifichero de un repositorio, cualquier escenario donde quieras coloreado consciente de la sintaxis como delta, o donde necesites canalizar la salida del diff hacia otra herramienta.
10. Unicode, CJK y RTL: notas para text diff internacional
El tokenizador parte por límites de palabra Unicode usando tres categorías: secuencias de palabra (letras \p{L} y dígitos \p{N}), puntuación que no es palabra y espacios en blanco. Cada categoría produce sus propios tokens, así que hello, world! se convierte en hello, ,, , world, !: cinco tokens.
Para contenido CJK (chino, japonés, coreano), cada ideograma o kana es su propio token. Cambia un carácter en una frase china y solo ese carácter lleva el resalte inline mientras el resto de la línea queda apagado. La estructura a nivel de párrafo sigue siendo por líneas, así que reescribir una frase añadiendo un salto de línea aparece como edición a nivel de línea, no de token.
Para idiomas RTL (árabe, hebreo), el diff usa direcciones CSS lógicas (ms-, me- en lugar de ml-, mr-). En locales RTL el canalillo y las columnas de línea se voltean de forma natural; dentro de cada celda del diff, la dirección del texto sigue al contenido, así que las cadenas en árabe se renderizan de derecha a izquierda mientras los marcadores + y - se mantienen alineados al canalillo de inicio.
La normalización de fin de línea reconoce \r\n (Windows), \n (Unix) y \r solo (Mac OS clásico hasta la versión 9). Las tres se parten como líneas separadas, así que un archivo convertido de una plataforma a otra no se colapsa en una sola megalínea.
11. Preguntas frecuentes
¿Cómo funciona un text diff online?
Un text diff parte ambas entradas en líneas, ejecuta un algoritmo de Longest Common Subsequence (habitualmente Myers O((N+M)D)) para encontrar el conjunto mínimo de inserciones y eliminaciones, y luego resalta las líneas añadidas (verde), eliminadas (rojo) y sin cambios (gris). Una segunda LCS a nivel de token marca las palabras cambiadas dentro de cada línea modificada. Text Diff ejecuta toda la comparación en local dentro de tu navegador.
¿Cuál es la diferencia entre text diff y JSON diff?
Text diff compara línea a línea: ideal para prosa, código, logs y contratos. Comparar JSON Online entiende el modelo de datos de JSON: el orden de las claves es irrelevante, los tipos son estrictos (1 ≠ "1"), los arrays pueden emparejarse por clave. Pega JSON en un text diff y los reordenamientos de claves o los espacios en blanco aparecerán como cambios que JSON Diff ignora. Usa text diff para contenido sin estructura, JSON Diff para respuestas de API y configuraciones.
¿Por qué el diff muestra líneas enteras cambiadas si solo edité una palabra?
No lo hace: la línea aparece resaltada porque algo en ella cambió, pero dentro del resalte solo los tokens cambiados llevan el fondo brillante (verde para añadido, rojo tachado para eliminado). Es el diff intralínea a nivel de palabra: el contexto de la línea queda legible mientras tu vista cae sobre la edición exacta. Cuando demasiado de una línea ha cambiado para que el resalte por palabra sea útil, el diff recurre a un par separado de eliminación + adición para que la estructura quede limpia.
¿Cómo ignoro espacios en blanco, mayúsculas o líneas en blanco en el diff?
Activa el panel de opciones de ignorar. Ignore case hace que A y a sean iguales. Ignore all whitespace colapsa cada espacio, tabulación y salto de línea, equivalente a git diff -w. Ignore trailing spaces and tabs refleja git diff -b y silencia el ruido CRLF. Ignore blank lines descarta líneas vacías para que el reespaciado de párrafos deje de desalinear el diff. Cada opción es independiente y persiste entre sesiones.
¿Qué es el formato de diff unificado?
El diff unificado es el formato de texto ---/+++/@@ -L,C +L,C @@ introducido por GNU diff a finales de los 80 y usado por git, GitHub, GitLab y el comando Unix patch. Cada hunk muestra tres líneas de contexto alrededor del cambio, con - para eliminado y + para añadido. Copia la salida unified en un comentario de PR, pégala en git apply o ejecuta patch -p1 < diff.patch y se aplica limpiamente.
Myers vs Patience: ¿qué algoritmo de diff es mejor para code review?
Myers es el predeterminado en git diff y GNU diff. Es rápido y matemáticamente mínimo, pero a veces alinea líneas en blanco o llaves de cierre no relacionadas, produciendo diffs que «se leen raros». Patience (Bram Cohen, 2005) se ancla en líneas que aparecen exactamente una vez en cada entrada y recurre entre anclas, así que las fronteras entre funciones se mantienen intactas. Usa git diff --patience (o --histogram para resultados similares, algo más rápido) cuando revises refactors.
¿El texto que pego se envía a algún servidor?
No. Cada comparación en Text Diff se ejecuta en local en JavaScript dentro de tu navegador. Tu texto nunca se sube, se loguea, se guarda en disco ni se envía a un tercero. Solo tus preferencias de UI (modo de vista e interruptores de ignorar) se guardan en localStorage para que la página los recuerde la próxima visita, nunca el texto. Verifícalo con DevTools → Network: cero peticiones cuando haces clic en Diff.
¿Qué tamaño pueden tener las dos entradas?
El límite práctico es de unas 5000 líneas o 1 MB por lado. El diff en vivo se desactiva por encima de 200 KB combinados y cambia a un botón manual Diff. Por encima de 5000 líneas la entrada se trunca con un aviso. Para archivos de varios megabytes, cambia a diff -u a.txt b.txt, git diff --no-index a.txt b.txt o delta: hacen streaming y manejan gigabytes.