Pega la versión A a la izquierda, la versión B a la derecha y observa qué ha cambiado. Sin git clone, sin IDE, sin registro. Todo se ejecuta en tu navegador.
Una herramienta gratuita en el navegador para comparar dos versiones de código sin abrir Git, GitHub ni tu IDE. Pega la versión antigua a la izquierda y la nueva a la derecha; las diferencias se resaltan carácter por carácter. El texto nunca sale de tu equipo, lo que importa cuando el fragmento procede de un repo privado o de una rama sin fusionar.
Está pensada para el momento en que un compañero suelta dos versiones de una función en Slack y pregunta "¿qué ha cambiado?". Montar un checkout local para un diff de 12 líneas es excesivo. También lo es abrir la vista de PR de GitHub si todavía no existe el PR. Dos paneles de texto, un diff, listo en quince segundos.
Esto no sustituye a git diff sobre un working tree real. No puede preparar hunks, aplicar parches ni ejecutar blame. Lo que sí hace es la parte que más necesitas: coger dos bloques arbitrarios de texto y mostrarte las ediciones entre ellos. Por debajo, el diff usa el mismo motor que nuestra herramienta compare-text, adaptado para code review.
El diff trabaja carácter a carácter y luego una pasada de limpieza semántica reagrupa los cambios en bloques legibles, de modo que el resaltado cae sobre un identificador renombrado y no sobre cada letra individual. Las inserciones aparecen en verde en el panel derecho; las eliminaciones en rojo en el panel izquierdo. Ambos paneles se desplazan sincronizados, así que si encuentras un cambio en la línea 80 de un lado, el otro lado salta contigo.
¿Por qué a nivel de carácter en lugar de línea? Porque para fragmentos cortos la vista solo por líneas es demasiado tosca. Renombrar una variable de id a userId es un único cambio de identificador; un diff por líneas mostraría toda la línea borrada más una línea nueva insertada, lo cual es técnicamente cierto pero hace más difícil ver la edición real. El modo carácter con limpieza semántica resalta el token renombrado y deja el resto de la línea en paz. Para archivos largos la balanza se invierte, y por eso el diff clásico por líneas es lo que Git usa por defecto. Cada uno tiene su sitio. Esta herramienta te da la vista buena para fragmentos.
Lo que la herramienta deliberadamente no hace: no entiende sintaxis. No parsea JavaScript, Python ni Java. Un bloque reformateado con la misma semántica seguirá apareciendo como diferencia, porque para un comparador de texto es texto distinto. Si quieres diff con conocimiento de formato para payloads estructurados, nuestra página compare-json lo hace para JSON, compare-yaml para YAML y compare-xml para XML y archivos POM. Para código fuente puro, el diff de texto más tu propia vista suele ser más rápido que configurar una herramienta semántica para algo puntual.
Dos paneles de texto, un diff. Sin login, sin subida, sin formato de parche que parsear.
Copia la versión antigua de la función, archivo o fragmento desde tu editor, terminal o donde sea que esté. Ctrl+C y pega en el panel izquierdo. Si tiras de git show <commit>, copia el cuerpo del archivo y no la cabecera del parche, para que el diff resalte solo cambios reales de código.
Haz lo mismo con la versión nueva. Si un compañero la pegó en Slack, Teams o un correo, copia directamente desde ahí. Los espacios y la indentación se preservan al pegar, lo que importa en lenguajes donde la indentación es significativa, como Python y YAML. Tab vs espacios saldrá como diferencia si los dos fragmentos no coinciden.
Las eliminaciones aparecen tachadas en rojo a la izquierda; las inserciones en verde a la derecha. Los contadores de cambios en cada cabecera te dicen cuántas ediciones distintas se han detectado. Lee los resaltados, fíjate primero en cambios de lógica (flujo de control, condicionales, manejo de errores) y deja los renombrados puros o cambios de formato como prioridad menor en la pasada de revisión.
Alguien suelta dos bloques de código en el chat y pregunta cuál es el correcto. Clonar el repo, cambiar de rama y abrir tu IDE para un fragmento de 20 líneas es esfuerzo desperdiciado. Pega ambos en la herramienta de diff y tienes la respuesta antes de que llegue el siguiente mensaje. Es la razón más común por la que la gente recurre a un diff online.
Pipelines de CI, Dockerfiles, package.json y YAML de workflows de GitHub Actions cambian constantemente. Un compañero edita .github/workflows/ci.yml en una rama, el build rompe y quieres ver qué ha cambiado sin hacer checkout de su rama. Pega la versión de main junto a la rama rota y el paso que falla suele aparecer en segundos. Para archivos de workflow, nuestra página de YAML diff maneja casos de indentación con más limpieza.
Product managers, diseñadores y account managers a veces necesitan saber qué hace un cambio de código sin leer una interfaz de Git. La vista de PR de GitHub asume familiaridad con sintaxis de diff, árboles de archivos y comentarios de revisión. Pegar el antes y el después en una vista limpia de dos paneles, y repasar los resaltados juntos, es mucho más amable. Útil también en postmortems donde el público incluye gente fuera de ingeniería.
Tienes la salida de git show abc123 y de git show def456 para un archivo en dos commits, quizá desde un log de CI o un sandbox remoto donde no puedes ejecutar comandos git con facilidad. Quita las cabeceras del parche, pega los dos contenidos del archivo y compara. Funciona bien cuando depuras en un servidor, lees un artefacto de build o revisas un aviso de seguridad que cita contenidos de archivo de dos commits concretos.
Un proveedor envía una integración de ejemplo en PDF. Un regulador te manda por email un fragmento de código normativo. Una consultora adjunta una versión parcheada de tu script. Nada de eso viene como repo clonable. Copia el texto del PDF o del correo, pégalo junto a tu versión actual y tienes una superficie de revisión utilizable en menos de un minuto. Espera algo de ruido de formato al pegar desde PDF; saltos de línea y comillas son los sospechosos habituales.
Los casos en los que un diff de texto plano discrepa con lo que mostrarían Git, tu IDE o tu herramienta de code review. Conviene revisarlos antes de pegar código de producción y preocuparse por un falso positivo.
| Topic | What this tool does |
|---|---|
| Line endings (CRLF vs LF) | CRLF al estilo Windows y LF al estilo Unix son bytes distintos. Un archivo pegado desde un editor Windows y otro pegado desde un contenedor Linux saldrán como diff completo si los line endings no coinciden, aunque el texto visible sea idéntico. Git lo normaliza con core.autocrlf; esta herramienta no. |
| Espacios al final de línea | Espacios o tabs al final de una línea saldrán como diferencia. core.whitespace de Git puede avisar o autocorregir al hacer commit; aquí, lo que pegas es lo que comparas. Si tu code review tiene un suelo de ruido lleno de cambios de espacios al final, recórtalos en el editor antes de comparar. |
| Archivos binarios | Esta herramienta es solo de texto. Pegar el contenido de un archivo binario (un PNG, un JAR compilado, una BD sqlite) producirá basura o colgará la pestaña. Para diff binario, Git muestra "Binary files differ" en lugar de un parche; necesitas tooling específico del formato para el contenido real. |
| Marca text vs binary en .gitattributes | El .gitattributes de un repo puede sobrescribir la detección texto vs binario de Git por patrón de archivo. Esa configuración no viaja con un copia-pega. Si sospechas que un archivo se trata distinto entre dos checkouts, ese archivo es donde mirar; esta herramienta lo comparará como texto plano de todos modos. |
| Diff por carácter vs por línea | Esta página usa diff a nivel de carácter con limpieza semántica. Git va por línea por defecto, con git diff --word-diff opcional para nivel de palabra. Carácter va mejor para fragmentos cortos donde cambia un único token; línea va mejor para archivos largos donde cambian muchas líneas a la vez. |
| git diff --word-diff | El modo --word-diff de Git resalta cambios a nivel de palabra dentro de una línea, más cercano a lo que esta herramienta hace para fragmentos. El formato de salida es distinto (markup amigable para terminal vs paneles lado a lado), pero la intención coincide. Si vives en la terminal, --word-diff es el equivalente local. |
| Umbrales de archivos grandes | Los diffs en navegador responden bien hasta unos miles de líneas por lado. Más allá, la limpieza semántica se ralentiza y el DOM renderizado pesa. Para archivos enormes, ejecuta git diff localmente y pásalo a un pager, o trocea la comparación en secciones más pequeñas. |
| Codificación (solo UTF-8) | El diff asume entrada UTF-8, que cubre casi todo el código fuente en 2026. Archivos guardados como UTF-16, Windows-1252 o Shift-JIS pueden salir como mojibake al pegar, según tu navegador. Si un fragmento sale como caracteres raros, vuelve a guardar el archivo fuente como UTF-8 antes de copiar. |
El git diff local compara dos refs (commits, ramas, working tree) dentro de un repositorio real. Conoce tu index, tu worktree y tu historial. Esta herramienta online no hace nada de eso. Compara dos bloques arbitrarios de texto que pegas. Usa git diff para revisión real sobre un repo con checkout. Usa esto cuando tienes dos fragmentos y ninguna forma cómoda de meterlos en un working tree, o cuando quieres una vista lado a lado sin cambiar de contexto.
No del todo. GitHub y GitLab usan unified diff por líneas con contexto de archivo, cabeceras de hunk y resúmenes por archivo. Esta herramienta usa diff a nivel de carácter con limpieza semántica, mejor para fragmentos cortos y peor para diff de archivos enteros con muchos cambios. Para una revisión real de pull request ve a la vista de PR de GitHub. Para una comparación rápida fuera del PR, esto es más rápido y no obliga a navegar al repo correcto.
No. Es un diff de texto plano. No parsea el lenguaje, así que no puede saber que una variable renombrada es el mismo identificador en 12 sitios, ni puede ignorar reformateos de espacios como haría un diff con sintaxis. Para la mayoría de revisiones de fragmentos da igual, porque lees los resaltados con tu propia cabeza. Si necesitas diff semántico real para código, tu IDE (VS Code, IntelliJ) o un diff basado en tree-sitter es la herramienta adecuada. Esta página optimiza velocidad, no parsing profundo.
El comando clásico de Unix diff -u produce un parche en formato unificado (el mismo formato que Git usa por dentro). Es por líneas y está pensado para ser legible por máquina, de forma que puedas aplicar el parche en otro sitio. Esta herramienta es legible para humanos. Muestra dos paneles lado a lado con resaltado en línea, no una sola columna de líneas con más y menos. No produce un archivo de parche que puedas aplicar con git apply o patch -p1. Si necesitas generar un parche, usa la línea de comandos. Si necesitas leer un diff, esto es más amable.
Sí, pero a su manera. CRLF (Windows) y LF (Unix) saldrán como diferencia si los dos fragmentos pegados no coinciden, porque técnicamente son bytes distintos. Lo mismo con espacios al final de línea. Es coherente con cómo trata Git los archivos cuando core.autocrlf está desactivado. Si solo te importan los cambios de lógica y no los espacios, recorta cada panel antes de pegar. Aún no ofrecemos un toggle de "ignorar espacios", aunque está en la hoja de ruta; git diff -w es el equivalente local.
En la práctica sí. El diff corre en tu navegador, así que entradas muy grandes (toda una librería vendorizada o un archivo generado de 50.000 líneas) ralentizarán la página o bloquearán la pestaña según la memoria de tu navegador. Para revisión de código típica (funciones, archivos, scripts de build, configs hasta unos miles de líneas por lado) el diff acaba prácticamente al instante. Si necesitas comparar repositorios enteros, una herramienta Git real o una de comparación de carpetas es lo correcto; esta página está hecha para fragmentos y archivos sueltos.
Tu código nunca sale de tu navegador. El diff, el resaltado y el render se ejecutan en tu equipo. No subimos el texto, no lo registramos ni lo pasamos a ningún servicio de terceros. Esto importa concretamente en code review propietario: pegar una feature no publicada, un parche de seguridad o un fragmento de un repo privado en un servicio cloud puede ya violar la política de tratamiento de datos de tu empresa. Verificarlo es sencillo. Abre las DevTools del navegador, ve a la pestaña Network, pega ambas versiones y observa. No hay peticiones salientes al comparar. El mismo modelo de privacidad rige en nuestras otras herramientas, incluyendo compare-text, compare-json y compare-yaml. El code review funciona mejor cuando la superficie de revisión es de fiar.