Las pruebas de compatibilidad entre navegadores comprueban que las funciones y el diseño de un sitio web funcionan de forma coherente en todos los navegadores, versiones de navegador, sistemas operativos y dispositivos que admites, e incluyen corregir lo que falla. Las pruebas entre navegadores en general se centran en el proceso y las herramientas de prueba; las pruebas de compatibilidad se centran en las diferencias en sí: una función de CSS que un navegador aún no ha incorporado, un selector de fechas que se comporta de otra manera en Android o un inicio de sesión que falla cuando se bloquean las cookies de terceros.
¿Qué son las pruebas de compatibilidad entre navegadores?
Un navegador es compatible con tu sitio cuando todas las funciones que utilizas son compatibles y se muestran como pretendías. Las pruebas de compatibilidad, a menudo abreviadas como CBT, responden a tres preguntas:
- ¿Qué navegadores y versiones admitimos?
- ¿Funcionan todas las funciones que usamos en todos ellos, o recurren a una alternativa adecuada cuando no es así?
- ¿Ha roto algo la última versión de un navegador o nuestro último despliegue?
Las pruebas de compatibilidad más amplias también pueden abarcar sistemas operativos, hardware, lectores de pantalla y redes lentas, pero en los sitios web es en el navegador donde aparecen la mayoría de los problemas.
Por qué la compatibilidad sigue importando en 2026
- Tu audiencia se reparte entre motores. Las cifras de StatCounter de septiembre de 2026 dan a Chrome un 66,4 % del uso mundial de navegadores, a Safari un 18,3 %, a Edge un 6,0 %, a Firefox un 2,8 % y a Samsung Internet un 2,3 %. En móvil, Safari tiene un 24,7 %, y en Estados Unidos un 30,4 % en todos los dispositivos.
- Todos los navegadores del iPhone usan WebKit. Chrome, Firefox y Edge en iOS utilizan el motor de Apple (con una excepción limitada en la UE), por lo que un error de Safari afecta a todos los usuarios de iPhone, sea cual sea el navegador que hayan elegido.
- Las funciones llegan en momentos distintos. El CSS y el JavaScript nuevos se incorporan en cada navegador según su propio calendario, y las versiones antiguas perduran en dispositivos que ya no se actualizan.
- Búsqueda y conversiones. Google indexa la versión móvil de tus páginas, así que un diseño que se rompe en los teléfonos perjudica tanto a los visitantes como a la visibilidad.
Paso 1: define tu matriz de compatibilidad de navegadores
No puedes admitirlo todo, así que anota lo que sí admites. Parte de tus analíticas y agrupa los navegadores por niveles:
| Nivel | Navegadores habituales | Compromiso |
|---|---|---|
| A: compatibilidad total | Versiones actuales de Chrome, Safari (Mac e iPhone), Edge y Firefox; Samsung Internet si tienes tráfico de Android | Todo funciona y se ve tal como se diseñó; las pruebas automatizadas se ejecutan con cada cambio |
| B: funcional | Versiones antiguas que todavía aparecen en tus analíticas | Los recorridos principales funcionan; se aceptan pequeñas diferencias visuales |
| C: básico | Todo lo demás | El contenido es legible y los formularios se envían |
Guarda la matriz como una configuración de Browserslist para que herramientas de compilación como Autoprefixer y Babel apunten a los mismos navegadores. Baseline es un atajo útil: una función marcada como "Baseline: ampliamente disponible" funciona en todos los navegadores principales (Chrome, Edge, Firefox y Safari, en escritorio y móvil) desde hace al menos 30 meses, por lo que la mayoría de los sitios pueden usarla sin alternativa.
Cómo detectar y corregir problemas de compatibilidad
- Comprueba la compatibilidad antes de desarrollar. Consulta las funciones nuevas en MDN, cuyas páginas muestran tablas de compatibilidad de navegadores y el estado de Baseline, o en Can I use. El proyecto Baseline explica cómo se define ese estado.
- Detecta funciones, no navegadores. Envuelve el CSS más reciente en
@supportsy comprueba en JavaScript que una API existe antes de llamarla, en lugar de adivinar a partir de la cadena del agente de usuario. - Construye con mejora progresiva. Haz que el contenido y los formularios funcionen primero con HTML y CSS básicos, y añade después las funciones más nuevas por encima.
- Automatiza las correcciones rutinarias. Autoprefixer añade los prefijos de proveedor, Babel y los polyfills cubren los motores de JavaScript antiguos, y linters como eslint-plugin-compat avisan cuando el código usa algo que tus objetivos de Browserslist no admiten.
- Prueba en los tres motores. Playwright ejecuta las mismas pruebas en Chromium, Firefox y WebKit, y sus comparaciones de capturas de pantalla detectan desajustes en el diseño.
- Confirma en dispositivos reales. Los emuladores y los modos de diseño adaptable sirven para una primera pasada, pero los teclados en pantalla, la interacción táctil, el desplazamiento y el vídeo se comportan de otra manera en teléfonos reales. Usa tus propios dispositivos o una plataforma en la nube como BrowserStack, TestMu AI (antes LambdaTest), Sauce Labs o BitBar.
- Prueba con las protecciones de privacidad activadas. La prevención de rastreo de Safari, el modo estricto de Firefox y Shields de Brave pueden bloquear scripts, cookies e incrustaciones de los que depende tu sitio.
Problemas de compatibilidad habituales en 2026
| Problema | Dónde aparece | Solución habitual |
|---|---|---|
| Las secciones de altura completa saltan o quedan ocultas tras la barra de herramientas | Navegadores móviles, sobre todo Safari en iPhone | Usa unidades de viewport dinámicas como dvh en lugar de vh |
| Se ignoran funciones de CSS recientes | Navegadores que aún no han incorporado la función, dispositivos antiguos | Comprueba el estado de Baseline y añade alternativas con @supports |
| Los campos de fecha, hora y selección se ven y se comportan de forma distinta | Todos los navegadores, que usan sus propios selectores nativos | Acepta los controles nativos o usa una biblioteca de componentes bien probada |
| El vídeo no se reproduce automáticamente o no se reproduce dentro de la página | Navegadores móviles y Safari | Reproduce automáticamente solo vídeo sin sonido y añade playsinline para iPhone |
| Fallan los inicios de sesión, pagos o widgets de chat incrustados | Safari, Firefox y Brave, que restringen las cookies de terceros | Prefiere flujos dentro del propio sitio o la Storage Access API, y prueba con la configuración de privacidad predeterminada |
| El texto se ajusta de otra forma y los botones se desbordan | Distintas fuentes y renderizado de fuentes en Windows, macOS y Android | Define fuentes alternativas y deja margen en botones y menús |
Lista de comprobación de compatibilidad entre navegadores
- Matriz de compatibilidad documentada y guardada como configuración de Browserslist.
- Funciones nuevas comprobadas en MDN, Can I use o Baseline antes de usarlas.
- Alternativas preparadas para todo lo que no esté clasificado como «Baseline: ampliamente disponible».
- Pruebas automatizadas superadas en Chromium, Firefox y WebKit.
- Formularios, vídeo y desplazamiento comprobados en un iPhone real y en un teléfono Android real.
- Inicios de sesión, pagos e incrustaciones probados con las protecciones de privacidad predeterminadas activadas.
- Páginas específicas por región y verificaciones de bots probadas desde otras ubicaciones y con otras huellas digitales del navegador (consulta cómo probarlas).
- Pruebas repetidas después de cada versión importante de un navegador.
Preguntas frecuentes
¿Necesito pruebas de compatibilidad si mi sitio web se ve bien en Chrome?
Sí. Chrome abarca aproximadamente dos tercios del uso mundial de navegadores, pero solo Safari representa cerca de un tercio de las visitas en Estados Unidos, y todos los navegadores del iPhone funcionan con el motor de Safari. Si pruebas solo en Chrome, dejas sin comprobar a una gran parte de los visitantes.
¿Con qué frecuencia debo hacer pruebas de compatibilidad?
Ejecuta comprobaciones automatizadas con cada cambio de código y después de las versiones importantes de los navegadores, y haz una revisión manual en dispositivos reales antes de lanzamientos o rediseños significativos.
¿Son caras las pruebas de compatibilidad?
No tienen por qué serlo. Playwright, Selenium y Cypress son gratuitos, igual que los datos de MDN, Can I use y Baseline. Las plataformas de pago en la nube sirven sobre todo para ahorrarte comprar y mantener tu propio laboratorio de dispositivos.
¿Cuál es la diferencia entre las pruebas entre navegadores y las pruebas de compatibilidad?
Las pruebas entre navegadores son el proceso general de probar en distintos navegadores, que tratamos en nuestra guía de pruebas entre navegadores. Las pruebas de compatibilidad se centran en si las funciones y el código concretos que usas son compatibles, y en cómo corregir o sortear las carencias.
