Diff Checker

Compare two texts character/word/line. Generate unified patch. Browser-only.

text-regex

Diff Checker

Original
Modified

Runs entirely in your browser. Your input never leaves your device.

What next?

How it works

Qué es un diff

Un diff es una descripción mínima de cómo transformar un texto en otro. En lugar de mostrar dos documentos completos, un diff resalta solo lo que cambió: adiciones, eliminaciones y líneas de contexto alrededor de ellas. Este es el mismo concepto detrás de git diff, patch(1) y cualquier herramienta de revisión de código que hayas utilizado.

El algoritmo subyacente en la mayoría de las herramientas diff modernas, incluida la biblioteca diff que impulsa esta herramienta, es Longest Common Subsequence (LCS). LCS encuentra la secuencia más larga de elementos presentes en ambas entradas en el mismo orden, y luego trata todo lo que no está en esa secuencia como agregado o eliminado. Calcular LCS es O(n²) en el peor caso, pero las implementaciones prácticas usan el algoritmo de Myers que es mucho más eficiente para entradas típicas.

Diff a nivel de línea vs nivel de palabra

Hay dos granularidades que te importarán:

Diff a nivel de línea divide cada texto en líneas, ejecuta LCS sobre esas líneas y reporta líneas completas como agregadas, eliminadas o sin cambios. Este es el predeterminado de git diff. Es ideal para código fuente porque las líneas son la unidad natural de cambio — agregar una función significa agregar múltiples líneas, y el diff a nivel de línea lo captura limpiamente.

Diff a nivel de palabra (también llamado "intra-línea") divide el texto más y calcula LCS sobre palabras individuales o incluso caracteres. Esto revela cuáles palabras dentro de una línea cambiada fueron modificadas. Es invaluable para prosa, contratos y blobs JSON donde una línea puede tener 200 caracteres pero solo cambió un valor.

Usa diff a nivel de línea al revisar código o configuración. Usa diff a nivel de palabra al comparar documentos, markdown, respuestas de API o cualquier texto donde importe la precisión sub-línea.

Formato unificado vs en paralelo

Formato unificado es la salida tradicional de diff -u: líneas de contexto prefijadas con espacio, eliminaciones con -, adiciones con +. Un encabezado de hunk unificado se ve como @@ -12,7 +12,9 @@, que significa "comenzando en la línea 12 del archivo antiguo, 7 líneas; comenzando en la línea 12 del archivo nuevo, 9 líneas." Este formato es compacto y amigable para grep; es lo que produce git diff y lo que consume patch.

Formato en paralelo muestra la versión antigua a la izquierda y la nueva a la derecha, con líneas eliminadas resaltadas en la columna izquierda y líneas insertadas en la derecha. El formato en paralelo es más fácil de leer para humanos revisando diffs grandes — puedes ver antes y después sin cambiar mentalmente de contexto. La mayoría de las UIs de revisión de código (GitHub, GitLab, Bitbucket) tienen el paralelo como predeterminado.

Cuándo usar una herramienta diff

Preparación de revisión de código. Antes de abrir un pull request, pega ambas versiones de una función crítica en un diff checker para verificar que el delta es exactamente lo que pretendías — sin cambios accidentales de espacios en blanco, sin console.log de depuración olvidados.

QA de contenido. Comparar dos borradores de un artículo o página de documentación es mucho más rápido con un diff de palabras que leyendo ambos manualmente. Una sola oración cambiada salta inmediatamente.

Contratos y texto legal. Incluso cambiar "deberá" por "podrá" tiene significado legal; un diff a nivel de palabra lo detecta al instante.

Deriva de configuración. Cuando el archivo de configuración de un servidor diverge de la versión en control de fuente, un diff a nivel de línea señala exactamente qué líneas fueron tocadas.

Cambios en respuestas de API. Pega la respuesta de ayer junto a la de hoy para detectar deriva del esquema — especialmente útil durante actualizaciones de API de terceros.

Limitaciones que debes entender

Textual, no semántico. Una herramienta diff compara secuencias de caracteres. No tiene comprensión del significado. Renombrar una función de getUser a fetchUser en 500 líneas parece 50 cambios separados aunque lógicamente es un solo refactor.

Sensibilidad a espacios en blanco. Por defecto, un espacio al final o una discrepancia tab-vs-espacio cuenta como cambio. Activa la opción Ignorar espacios en blanco para filtrar diferencias insignificantes de espaciado.

Entradas grandes. La complejidad del algoritmo LCS crece con entradas muy grandes. Para archivos de decenas de miles de líneas, diff en línea de comandos o una herramienta con soporte de streaming rendirá mejor.

Sin lógica de merge. Un diff muestra qué cambió. No combina automáticamente dos versiones divergentes ni resuelve conflictos — ese es el problema de three-way merge que manejan git merge y diff3.

Privacidad

Todo el cálculo diff ocurre completamente en tu navegador usando la biblioteca open-source diff. Ninguna versión de tu texto se transmite a un servidor. Esto es particularmente importante al comparar documentos sensibles — contratos confidenciales, archivos de credenciales o código fuente privado. Abre la pestaña Network de tu navegador mientras ejecutas un diff: verás cero solicitudes salientes.

Herramientas relacionadas

  • Regex Tester — valida y itera con expresiones regulares antes de usarlas en flujos de trabajo de buscar y reemplazar.
  • Text Case Converter — normaliza inconsistencias de capitalización antes de hacer diff para reducir el ruido.

FAQ

¿Qué algoritmo usa el diff checker?

La herramienta usa el algoritmo Longest Common Subsequence (LCS), específicamente el algoritmo de Myers implementado en la biblioteca open-source diff. El algoritmo de Myers encuentra el script de edición mínimo entre dos secuencias en tiempo O(ND), donde N es la suma de las longitudes de entrada y D es el tamaño del diff. Para entradas típicas esto es mucho más rápido que el peor caso teórico O(n²) del LCS ingenuo.

¿Cuál es la diferencia entre diff a nivel de línea y nivel de palabra?

El diff a nivel de línea trata cada línea como una unidad atómica — las líneas completas se marcan como agregadas, eliminadas o sin cambios. El diff a nivel de palabra (intra-línea) divide más en tokens individuales y resalta exactamente qué palabras cambiaron. Usa nivel de línea para código fuente donde las líneas son unidades naturales; usa nivel de palabra para prosa, contratos o JSON donde un valor importante puede cambiar dentro de una línea larga.

¿Qué significa el encabezado @@ en la salida diff unificado?

El encabezado de hunk @@ -12,7 +12,9 @@ significa: en el archivo original, el hunk comienza en la línea 12 y abarca 7 líneas; en el archivo modificado comienza en la línea 12 y abarca 9 líneas. Las líneas prefijadas con - fueron eliminadas, las líneas con + fueron agregadas, y las líneas con espacio son contexto sin cambios. Este es el formato estándar producido por diff -u y consumido por patch.

¿Puedo usar esto para comparar archivos de código fuente?

Sí — pega las dos versiones de tu archivo en las áreas de texto y ejecuta el diff. Para preparación de revisión de código es especialmente útil para detectar cambios accidentales (logs de depuración olvidados, modificaciones de espacios en blanco no deseadas) antes de abrir un pull request. Para comparar repositorios completos o rastrear historial, usa git diff ya que tiene acceso al grafo completo de commits.

¿Por qué mi diff muestra cambios que no hice (ruido de espacios en blanco)?

Los editores frecuentemente difieren en espacios en blanco al final, estilo de fin de línea (CRLF vs LF) o indentación (tabs vs espacios). Activa la opción Ignorar espacios en blanco para eliminar diferencias insignificantes de espaciado antes de ejecutar el LCS. Para problemas persistentes, normaliza los finales de línea primero con dos2unix o la configuración "trim trailing whitespace" de tu editor.

¿Mi texto se envía a un servidor?

No. Todo el diff se calcula en tu navegador por la biblioteca diff — una implementación pure JavaScript sin llamadas al servidor. Tu entrada nunca sale de tu dispositivo, lo que lo hace seguro para usar con contratos confidenciales, código fuente privado o cualquier texto que no quisieras transmitir por una red. Puedes verificarlo abriendo la pestaña Network de tu navegador mientras ejecutas un diff.

¿Cuáles son los límites de tamaño de entrada?

Prácticamente, hasta unos pocos cientos de kilobytes por lado funciona sin problemas. Más allá de eso, el tiempo de cálculo del LCS crece y el navegador puede pausar momentáneamente. Para comparar archivos grandes (logs de múltiples MB, volcados SQL grandes), diff en línea de comandos o una herramienta dedicada con soporte de streaming funcionará mejor.

¿Puede el diff checker detectar bloques de texto renombrados o movidos?

No — el diff basado en LCS es puramente posicional y secuencial. Si mueves un párrafo del principio de un documento al final, el diff mostrará la ubicación original como eliminada y la nueva ubicación como insertada, no como un "movimiento." Detectar movimientos requiere una capa semántica (hashing de similaridad, análisis AST) más allá de lo que proporciona un diff de texto.