Nivel inicial18 min de lectura · Publicado el 28 de junio de 2018

Chrome DevTools (Developer Tools): guía, atajos y paneles

Las Chrome DevTools (Chrome Developer Tools) son las herramientas para desarrolladores que trae Google Chrome. Con ellas ves el HTML y el CSS que forman la página, los errores de JavaScript, cada fichero que descarga y cuánto tarda, y puedes cambiar piezas en vivo para probar un arreglo antes de tocar tu código. Una web en el navegador es como un coche con el capó cerrado: sabes que funciona, o que no, pero no ves por qué. Las DevTools abren el capó.

Esta guía va al grano: cómo abrirlas, atajos, cada panel con un caso práctico y cómo usarlas desde código o con un agente de IA. Todo se ha comprobado en la documentación oficial con Chrome 157, la versión estable en noviembre de 2026.

Cómo abrir las Chrome DevTools

La propia documentación de Chrome da un truco para recordarlos: C de CSS, J de JavaScript e I para lo que elijas.

Sin teclado: clic derecho sobre cualquier elemento › Inspeccionar, o menú de los tres puntos › Más herramientas › Herramientas para desarrolladores.

Si quieres que se abran solas en cada pestaña, arranca Chrome desde la terminal con la opción --auto-open-devtools-for-tabs. Solo funciona si no había otro Chrome abierto:

google-chrome --auto-open-devtools-for-tabs

En Windows es start chrome --auto-open-devtools-for-tabs y en macOS, open -a "Google Chrome" --args --auto-open-devtools-for-tabs.

No confundir con Chrome Dev ni con Chrome for Developers

Chrome DevTools son las herramientas de este artículo, dentro de cualquier Chrome. Chrome Dev es un canal de versiones, como Beta o Canary: según el proyecto Chromium, se actualiza una o dos veces por semana, con más riesgo de fallos, y trae las mismas DevTools, solo que más nuevas. Chrome for Developers (developer.chrome.com) es la web de documentación de Google.

Chuleta de atajos de DevTools

Funcionan con las DevTools abiertas y el foco dentro de ellas.

El menú de comandos merece un sitio aparte: es el buscador de las DevTools. Escribe lo que quieres hacer («screenshot», «disable JavaScript», «dark»…) y no tendrás que recordar en qué menú estaba.

Elements: el HTML y el CSS en vivo

El panel Elements muestra el árbol del documento tal como está ahora, después de que el JavaScript lo haya modificado, que no siempre coincide con el HTML que enviaste. A la derecha, la pestaña Styles enseña las reglas CSS que se aplican al elemento seleccionado.

Caso práctico: «mi CSS no se aplica».

1. Clic derecho sobre el elemento › Inspeccionar.
2. En Styles, busca tu regla. Si la declaración aparece tachada, otra regla la está pisando (por especificidad, por ir después o por !important) o el valor no es válido, y entonces lleva un icono de aviso. Si sale en un texto más pálido, está inactiva: no tiene efecto en ese elemento. Si no aparece, el selector no coincide o la hoja de estilos no se ha cargado (eso se ve en Network).
3. Si el estilo depende de :hover o :focus, pulsa :hov y marca el estado: el elemento se queda «congelado» en ese estado mientras lo inspeccionas.
4. En la pestaña Computed ves el valor final de cada propiedad, con Show All para incluir las heredadas.
5. Prueba el arreglo editando el valor en Styles o añadiendo una clase con .cls. Cuando funcione, cópialo a tu fichero CSS: los cambios hechos en DevTools se pierden al recargar. La pestaña Changes recoge lo que has tocado para que no se te olvide nada.

Atajo útil: con un elemento seleccionado, la tecla H lo oculta. Sirve para ver qué hay debajo de un modal o descubrir qué elemento provoca un desbordamiento horizontal.

Console: errores y JavaScript sobre la página

La Console tiene dos usos. El primero, leer: aquí salen los errores de JavaScript, los recursos que no cargan y los mensajes de console.log. Ante una página en blanco o un botón que no hace nada, es el primer sitio donde mirar.

El segundo, escribir: lo que tecleas se ejecuta sobre la página abierta. Además del JavaScript normal, la consola trae unas utilidades propias que no existen en tus scripts:

Por ejemplo, para sacar todos los enlaces de una página o contar las imágenes sin texto alternativo:

$$('a').map((a) => a.href)
$$('img:not([alt])').length

En una página de prueba con dos enlaces y dos imágenes, una de ellas sin alt, el resultado es:

["https://example.com/a", "https://example.com/b"]
1

Envuelve la primera línea en copy(...) y tendrás la lista en el portapapeles, lista para pegar en una hoja de cálculo.

Ojo con $: si la página carga una librería que usa ese nombre, como jQuery, su $ sustituye al de la consola.

Sources: depurar JavaScript con breakpoints

Llenar el código de console.log funciona, pero es lento: cada duda es una edición y una recarga. En Sources pones un punto de ruptura (breakpoint) y el navegador se detiene en esa línea con todo a la vista: el valor de cada variable, quién llamó a la función y el estado de la página en ese instante.

Abre el fichero con Ctrl + PCmd + P, haz clic en el número de línea y recarga o repite la acción. Con clic derecho sobre el número de línea tienes dos variantes muy útiles:

• Add conditional breakpoint: solo se detiene si se cumple una condición, por ejemplo usuario.id === 42. Ideal para un bucle que falla en una vuelta concreta.
• Add logpoint: escribe un mensaje en la consola sin detenerse. Es un console.log que no ensucia tu código.

Hay más tipos: al cambiar un nodo del DOM, al hacer una petición cuya URL contiene un texto (XHR/fetch breakpoints), al dispararse un evento como un clic (Event listener breakpoints) o al lanzarse una excepción. Desde tu propio código, la sentencia debugger; hace lo mismo que un breakpoint de línea cuando las DevTools están abiertas.

Ya detenido, avanza con los atajos de la chuleta: F10 para la siguiente línea, F11 para entrar en una función y F8 para continuar.

Network: qué descarga la página y cuánto tarda

El panel Network registra cada petición: el HTML, las hojas de estilo, las imágenes y las llamadas a tu API. De cada una ves el código de estado, el tamaño, el tiempo y, al pulsarla, las cabeceras y la respuesta.

Caso práctico: «la API falla y no sé por qué».

1. Abre las DevTools antes de que ocurra el fallo: Network solo registra lo que pasa con ellas abiertas, estés en el panel que estés (si ya ha pasado, recarga). Marca Preserve log si la acción cambia de página: así no se borra la lista.
2. Filtra por Fetch/XHR para ver solo las llamadas a la API.
3. Pulsa la petición en rojo. En Headers ves la URL exacta, el método y el código de estado; en Response, lo que devolvió el servidor, que muchas veces explica el error.
4. Para reproducirla fuera del navegador, clic derecho › Copy › Copy as cURL o Copy as fetch.
5. Si tarda, la pestaña Timing desglosa el tiempo en fases: cola, DNS, conexión y espera de la primera respuesta (TTFB).

Dos casillas de la barra superior se usan a diario. Disable cache desactiva la caché del navegador para que la página cargue como en la primera visita de un usuario. Y el desplegable de throttling simula una conexión más lenta (fast 4G, slow 4G, 3G u offline) para ver cómo se comporta tu web en el móvil de alguien con poca cobertura.

Para que un cambio de CSS o JavaScript «se vea» de una vez, mira cómo refrescar una página web sin caché, con los atajos de recarga forzada de cada navegador.

Application: cookies, almacenamiento y service workers

El panel Application enseña lo que la web guarda en tu navegador:

• Storage: localStorage, sessionStorage, IndexedDB, cookies y Cache storage. Puedes ver y editar sus valores, y borrar todo lo del sitio para probar como un usuario nuevo.
• Manifest y Service workers: las piezas de una aplicación web progresiva. Aquí ves si el manifiesto es válido, si el service worker está activo y qué ha guardado en caché.

Si estás creando una PWA (aplicación web progresiva), ese artículo explica qué revisar aquí para que Chrome ofrezca instalarla.

Caso práctico: un usuario dice que «la web le recuerda mal» (un idioma equivocado, un carrito con productos viejos). Busca la clave en Local storage o en Cookies, bórrala y recarga: si el problema desaparece, el fallo está en cómo se guarda ese dato.

Lighthouse: auditar rendimiento, accesibilidad y SEO

El panel Lighthouse analiza la página y devuelve una nota y una lista de mejoras en cuatro categorías: Performance, Accessibility, Best Practices y SEO. Tiene tres modos:

La documentación recomienda ejecutarlo en una ventana de incógnito, porque las extensiones influyen en el resultado, y avisa de que la carga del equipo también influye: no compares notas de máquinas distintas. Para investigar a fondo el rendimiento recomienda el panel Performance; sobre ese terreno, sigue con la máxima performance de pintado en el front.

Modo dispositivo: tu web en un móvil (aproximado)

Con Ctrl + Mayús + MCmd + Mayús + M la página se muestra con el tamaño de pantalla de un móvil. El desplegable Throttle de la barra del dispositivo ofrece Mid-tier mobile (red 3G rápida y CPU 4 veces más lenta) y Low-end mobile (3G lenta y CPU 6 veces más lenta).

Es una aproximación. La documentación oficial pide verlo como «una aproximación de primer orden» (traducción nuestra) de cómo se ve y se siente la página en un móvil: tu código sigue ejecutándose en el procesador de tu ordenador. Para medir de verdad, conecta un teléfono real con la depuración remota.

DevTools desde código: el Chrome DevTools Protocol (CDP)

Todo lo que hacen las DevTools pasa por un protocolo, el Chrome DevTools Protocol (CDP). Su documentación lo define como un protocolo basado en JSON que conecta lo que se depura (pestañas, workers) con las herramientas que lo depuran o lo automatizan, y lo divide en dominios como DOM, Debugger o Network (resumen nuestro). La propia interfaz de DevTools, Lighthouse y Puppeteer hablan con Chrome por ese canal.

La misma página avisa de que el CDP no es una API pública ni con soporte: puede cambiar sin previo aviso, y pide a las herramientas de terceros que no se conecten a él directamente, sino que usen productos oficiales construidos encima, como Puppeteer, ChromeDriver o Chrome DevTools for agents. Con Puppeteer puedes obtener desde un script lo que verías en Console y Network. Este ejemplo levanta una página de prueba con un error de JavaScript y una llamada a una API que no existe, y lo registra todo:

// inspeccionar.mjs: lo que verías en Console y Network, pero desde código.
import { createServer } from "node:http";
import puppeteer from "puppeteer-core";

const PAGINA = `<ul><li>uno</li><li>dos</li><li>tres</li></ul>
<script>console.log("Página cargada"); fetch("/api/usuario"); noExiste();</script>`;
const servidor = createServer((req, res) => {
  res.writeHead(req.url === "/" ? 200 : 404, { "Content-Type": "text/html; charset=utf-8" });
  res.end(req.url === "/" ? PAGINA : "");
}).listen(0);

const navegador = await puppeteer.launch({ executablePath: process.env.CHROME ?? "/usr/bin/google-chrome" });
const pagina = await navegador.newPage();
pagina.on("console", (m) => console.log(`[console.${m.type()}] ${m.text()}`));
pagina.on("pageerror", (e) => console.log(`[error] ${e.message}`));
pagina.on("response", (r) => console.log(`[network] ${r.status()} ${new URL(r.url()).pathname}`));
await pagina.setCacheEnabled(false); // como la casilla «Disable cache» de Network
await pagina.goto(`http://localhost:${servidor.address().port}/`, { waitUntil: "networkidle0" });

// $$() solo existe en la consola de DevTools y Puppeteer no tiene un método para usarlo: se pide por CDP.
const cdp = await pagina.createCDPSession();
const { result } = await cdp.send("Runtime.evaluate", { expression: "$$('li').length", includeCommandLineAPI: true });
console.log(`[consola] $$('li').length → ${result.value}`);
console.log(`[versión] ${await navegador.version()}`);
await navegador.close();
servidor.close();

Casi todo usa métodos de Puppeteer, que se mantienen aunque el protocolo cambie por debajo. Solo hay una llamada al CDP en bruto, Runtime.evaluate con includeCommandLineAPI, porque las utilidades de la consola ($$, $0…) no tienen método propio en Puppeteer. Es la línea que podría romperse en una versión futura de Chrome.

puppeteer-core no descarga ningún navegador: usa el Chrome que ya tienes. Si no está en /usr/bin/google-chrome, indica su ruta en la variable CHROME.

npm install puppeteer-core
node inspeccionar.mjs

[network] 200 /
[console.log] Página cargada
[error] noExiste is not defined
[network] 404 /api/usuario
[console.error] Failed to load resource: the server responded with a status of 404 (Not Found)
[network] 404 /favicon.ico
[console.error] Failed to load resource: the server responded with a status of 404 (Not Found)
[consola] $$('li').length → 3
[versión] Chrome/157.0.8103.38

Ejecutado con Node 24.21.0, puppeteer-core 25.16.0 y Google Chrome 157.0.8103.38 en Linux. El orden de algunas líneas puede variar entre ejecuciones, porque las peticiones van en paralelo. /favicon.ico lo pidió el navegador por su cuenta: no está en tu código, pero sí en Network.

La IA y las DevTools

Hay dos formas de juntarlas, y conviene no confundirlas.

Dentro de DevTools: AI assistance. Chrome integra Gemini en las DevTools para ayudarte con estilos, peticiones de red, ficheros fuente y rendimiento. Viene desactivado: se activa en Settings › AI assistance, aceptando las condiciones de Google, con sesión iniciada, siendo mayor de 18 años y desde un país compatible. La documentación avisa de que es experimental y de que puede generar información inexacta.

Ojo con lo que compartes. Según la página de uso de datos de Google, se envía tu pregunta y el contexto que eliges (el DOM y el CSS, las peticiones de red, los ficheros fuente o la traza de rendimiento). Pueden leerlo revisores humanos y, con una cuenta personal, usarse para mejorar los modelos; los datos se guardan hasta 18 meses. Por eso no conviene usarlo con código o datos de un cliente sin su permiso (consejo nuestro). En una empresa, el administrador puede desactivarlo con la política DevToolsGenAiSettings.

Fuera de DevTools: Chrome DevTools for agents. Google publica un servidor MCP, chrome-devtools-mcp, para que un agente de programación controle Chrome: navegar, emular un móvil, leer la consola y las peticiones, depurar y pasar auditorías de Lighthouse. La configuración genérica que da su repositorio para un cliente MCP es esta:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

@latest descarga la última versión cada vez que arranca. En un proyecto, es mejor fijarla ([email protected]) y actualizarla a propósito, como cualquier otra dependencia (consejo nuestro).

El repositorio advierte de que el cliente MCP puede inspeccionar y modificar cualquier dato del navegador o de DevTools, y pide no usarlo con información sensible o personal. Su documentación añade tres detalles:

• Perfil: por defecto abre un Chrome con un perfil propio, en ~/.cache/chrome-devtools-mcp/chrome-profile, que no se borra entre usos; con --isolated usa uno temporal. El riesgo está en --autoConnect: se conecta al Chrome que ya tienes abierto y ve todas las ventanas de ese perfil, con tus sesiones iniciadas.
• Estadísticas de uso: se envían por defecto; se desactivan con --no-usage-statistics.
• CrUX: las herramientas de rendimiento pueden enviar la URL de la traza a la API de CrUX de Google para traer datos de usuarios reales; se desactiva con --no-performance-crux.

La configuración para cada agente concreto está en su repositorio.

Interpretación nuestra, con el criterio de IA Limpia: las dos son útiles como un compañero que te dice dónde mirar. La sugerencia se prueba en DevTools y, si funciona, se lleva a tu código con su test o su revisión; qué entra en tu código lo decides tú.

Para seguir aprendiendo

• Documentación oficial de Chrome DevTools (en inglés).
• Chrome DevTools en el libro del Curso HTML5 desde cero.
• Vídeo «Sácale chispas a Chrome Developer Tools (DevTools)», de Ruben Bernardez.

Si depuras JavaScript a menudo, te vendrá bien la chuleta de JavaScript.

Fuentes

Comprobado el 9 de noviembre de 2026 en la documentación oficial, con Google Chrome 157.0.8103.38 (estable) en Linux:

• Chrome for Developers: Open Chrome DevTools, Keyboard shortcuts, Command Menu, CSS features reference, Find invalid, overridden, inactive, and other CSS, Console Utilities API reference, Pause your code with breakpoints, Network features reference, Application panel, Lighthouse panel, Device Mode, AI assistance, Data use and enterprise controls y Chrome DevTools for agents.
• Chrome DevTools Protocol: definición, dominios y alcance del soporte.
• chrome-devtools-mcp y su guía de uso avanzado.
• Chromium, Chrome release channels: qué es el canal Dev.
• El ejemplo de Puppeteer y los fragmentos de consola se han ejecutado con Node 24.21.0, puppeteer-core 25.16.0 y Chrome 157 sin interfaz; los atajos se han tomado de la documentación oficial.
• Los nombres de los menús en español pueden variar según la versión de Chrome.