¿Es compatible WebGPU con Chrome, Safari y Firefox?

Qué han activado los tres navegadores

Safari lo activó primero en bloque. Las notas de WebKit para Safari 26.0 lo dicen sin rodeos: WebGPU «lleva más de un año activado en Safari Technology Preview y ahora se publica en Safari 26.0 para macOS, iOS, iPadOS y visionOS».

Chrome llegó antes que nadie, pero por partes. Según la tabla de estado del propio grupo de trabajo de WebGPU, está activado por defecto en Mac, Windows y ChromeOS desde la versión 113, y en Android desde la 121 para equipos con GPU ARM, Qualcomm o Intel.

Firefox fue el último y también por fases: la 141 lo activó en Windows, y la 147, publicada el 13 de enero de 2026, dice que «el soporte de WebGPU está ahora activado para dispositivos con procesadores Apple Silicon en todas las versiones de macOS compatibles».

Con eso, la frase «ya está en los tres navegadores» es cierta. El problema es la frase siguiente.

Dónde no está todavía

La misma tabla del grupo de trabajo, que es la fuente que mantienen quienes escriben la especificación, marca varios huecos que no aparecen en los titulares:

• Firefox en Linux y en Android: activado en Nightly, no en la versión estable.
• Firefox en Mac con Intel: fuera. La 147 habla solo de Apple Silicon.
• Chrome en Linux: Intel Gen12 o posterior desde la 144, y NVIDIA desde la 147, esta última solo en Wayland y con el controlador 535.183.01 o superior.
• Chrome en Windows ARM64: detrás del flag --enable-unsafe-webgpu.

Ninguno de esos huecos es exótico. Un estudio con Linux, un portátil Mac de hace unos años o un Android con Firefox son equipos que entran en una web de cliente todos los días.

Por eso MDN no lo llama Baseline

Es la comprobación que más rápido zanja la discusión. La ficha de Navigator.gpu en MDN lleva el distintivo de disponibilidad limitada, con esta explicación: «Esta función no es Baseline porque no funciona en algunos de los navegadores más usados».

Conviene no confundir ese distintivo con la lista anual. Lo que entra en Baseline y en Interop cada año es otra cosa: aquí lo que dice MDN es que WebGPU todavía no cumple el criterio de estar en todos.

Hay además un detalle que no se ve en ninguna tabla. Que navigator.gpu exista no garantiza que haya GPU disponible: la documentación de requestAdapter() avisa de que «se resolverá a null si no hay un adaptador apropiado disponible». Un equipo con el controlador en lista negra o con una tarjeta vieja tiene la API y no tiene adaptador.

Qué significa para un visor 3D

Significa que el plan B no es una concesión, es el camino real de una parte del público. Y significa que hay que escribirlo antes de migrar, no después del primer aviso de un cliente.

Three.js ofrece rutas WebGPU y WebGL dentro del mismo ecosistema, lo que puede facilitar compartir escenas y recursos. Eso no convierte la migración en automática: materiales, efectos, rendimiento y funciones compatibles necesitan pruebas en ambos renderizadores. También hay que decidir qué ocurre cuando no aparece un adaptador: abrir WebGL, mostrar una alternativa útil o explicar el problema.

Cómo decidirlo con datos propios

La medición en los teléfonos concretos del cliente sigue siendo la parte que nadie publica, y es la que decide si una escena funciona: está en los límites de un visor 3D en móvil.

Qué pedir antes de migrar

Antes de tocar nada, tres cosas por escrito: el reparto de navegadores y sistemas de los últimos meses, qué escena se va a usar de prueba y qué pasa cuando no hay adaptador. Con eso, la migración a WebGPU es una decisión que se puede defender; sin eso, es un cambio de motor a ciegas que se nota en las visitas que no se quejan, que son casi todas.

Para revisar si a tu visor le compensa el cambio, cuéntanos en qué navegadores y equipos se abre hoy.