Browser developer tools let you inspect and debug the page that is already open, without changing the server or installing a separate website editor.
What browser developer tools are
Chrome DevTools and Firefox Developer Tools are built into their browsers. They inspect the document, styles, scripts, requests, storage, and runtime state of a page. Google's official Chrome DevTools documentation and Mozilla's Firefox DevTools documentation describe the current panels and browser-specific features.
Open DevTools from the browser menu, by inspecting an element, or with the shortcut documented for your browser and operating system. Panel names and shortcuts can differ, so treat one browser's instructions as a starting point rather than a universal interface.
Inspect HTML and CSS
Use Elements in Chrome or Inspector in Firefox to select a visible element, read its DOM position, review matched CSS, and temporarily edit properties. The changes affect only your current browser session unless you also update the source files. Check the box model, inherited styles, overridden declarations, pseudo-classes, and computed values when spacing or color does not match expectations.
Read Console errors carefully
The Console shows JavaScript errors, warnings, logged values, and commands evaluated in the page context. Start with the first relevant error, open its source location, and reproduce the action. Do not paste commands from strangers into the Console: code run there can act with the permissions of the current page and account session.
Inspect requests in Network
The Network panel records requests while DevTools is open. Chrome's official Network panel overview covers recording, filters, headers, responses, cache controls, throttling, and exports. Reload the page after opening the panel, filter by Fetch/XHR, document, script, image, or media, and inspect status, timing, request headers, response headers, and payloads.
A failed request can be caused by the URL, method, credentials, CORS, cache, service worker, proxy, server, or browser extension. The status code is evidence, not a complete diagnosis. Use the HTTP Status Code Lookup for a quick definition.
Test responsive layouts
Device emulation changes the viewport and can simulate selected conditions, but it is not a physical-device guarantee. Check narrow and wide widths, zoom, long text, keyboard navigation, touch targets, orientation, reduced motion, and real mobile browsers. Watch for horizontal overflow, hidden controls, fixed elements covering content, and text that no longer fits.
Inspect storage and service workers
Application or Storage panels expose cookies, local storage, session storage, IndexedDB, cache storage, manifests, and service workers. Avoid changing production account data casually. Use a test account, record the original value, and remember that clearing storage can sign you out or remove unsaved local state.
Use performance tools with a repeatable case
Record the same page, viewport, network condition, and interaction before and after a change. Separate network delay, JavaScript work, rendering, layout, and image cost. One fast local run is not proof of production performance, and DevTools being open can affect timing.
A safe debugging sequence
- Reproduce the problem and note the exact action and URL.
- Check Console for the first relevant error.
- Reload with Network open and inspect failed or unexpected requests.
- Inspect the affected element and computed CSS.
- Review storage or service workers only when the symptom points there.
- Test a minimal change, then update and verify the real source.
- Repeat on another browser or device when compatibility matters.