Chrome DevTools is the most powerful tool built into a web browser — and consistently the most underused by the people who would benefit from it most. Press F12 on any webpage and it opens immediately, with no setup, no installation, and no accounts required. What you get: a full inspection and analysis toolkit for every element on any website. You’ll find the complete rundown in our Chrome How-To Guides.
This guide focuses on the capabilities that are immediately useful for a broad range of users — not just developers. Checking how a site looks on mobile, identifying why a page loads slowly, copying exact colour values and fonts from a competitor’s site, diagnosing why a button isn’t working. If you manage or review websites, write content, or do anything that touches the web professionally, there’s something practical in here that you’re probably not using yet.
Opening DevTools and navigating the interface
Three equivalent routes to open it:
- F12: fastest — opens from any webpage in the last-used configuration
- Ctrl+Shift+I (Windows/Linux) / Cmd+Option+I (Mac): same result for those who prefer it
- Right-click any element → “Inspect”: opens with the Elements panel active and that specific element already selected — the most useful entry point when you want to examine something specific on the page
By default, Chrome DevTools docks to the right side of the browser window. The dock position is changed through the three-dot menu inside the DevTools panel itself (top-right of the DevTools interface, separate from the main Chrome menu) → Dock side → Right, Bottom, or Undock into a separate window. On wide monitors: right-side docking lets you see the page and DevTools simultaneously, which is ideal for watching real-time changes. On laptops: bottom docking gives the page its full width. On dual-monitor setups: undock into a separate window and put DevTools on the second screen entirely.
The main DevTools interface has a tab bar at the top: Elements, Console, Sources, Network, Performance, Memory, Application, and more. If the tab bar doesn’t show all panels at the current window width: click the >> icon at the right end to reveal the rest. For most everyday use, Elements, Network, Console, Device Mode, and Lighthouse cover the important ground.
The Elements panel — inspecting any part of any webpage
The Elements panel shows the live HTML of the current page as a collapsible tree — every element, every attribute, every piece of content has a corresponding entry here. Select any node in the tree and the corresponding visual element on the page highlights with an overlay showing its dimensions. The Styles sidebar to the right shows all CSS rules applied to the selected element — every property, its value, and which file or rule is the source.
Changes made in the Elements panel are immediate but entirely temporary — they exist only in your browser’s current rendering and disappear when you reload the page. The actual website is unchanged by anything done in DevTools. This makes it a safe place to experiment: toggle styles, change text, test layout changes, and see results in real time without any risk of affecting the live site.
The element inspector — the arrow-and-box icon in the top-left of the DevTools toolbar, or Ctrl+Shift+C — is the fastest way to examine a specific element. Activate it, hover over any part of the page, and DevTools overlays a blue highlight with dimension labels and simultaneously highlights the corresponding node in the Elements tree. Click to “lock” the selection. The result: you can click anything on any website and immediately see exactly what HTML is behind it and what CSS is styling it.
Finding exact colour values and fonts from any website: activate the inspector, click the element, then look in the Styles sidebar for color, background-color, and font-family properties. Hovering over the colour swatch next to any colour value opens a colour picker showing the exact hex or RGB value. This is considerably more reliable than screenshot colour pickers, which can be affected by display calibration and JPEG compression. Designers, content creators, and marketers use this constantly to identify exact brand colours and fonts from competitor sites or design references — it takes 20 seconds once you know where to look.
The Network panel — understanding exactly why pages load slowly
The Network panel records every resource the browser requests when loading or interacting with a page — HTML, CSS, JavaScript, images, fonts, API responses, tracking scripts, everything. For each request: name, type, size, and load duration. The Waterfall column shows a visual timeline of when each request started and completed, making blocking relationships between resources immediately visible.
To use it: open DevTools → click Network tab → reload the page with Ctrl+R. The panel populates in real time. Resources with long bars took a long time; resources that start late were blocked by earlier loads. A few things to look for immediately:
- Size column: images larger than 200-300KB are strong candidates for compression — modern WebP format can reduce JPEG file sizes by 50-70% with no visible quality difference
- Long bars that start at the beginning: large JavaScript files that block everything else from loading
- Many sequential requests: resources that don’t load in parallel
The filter buttons at the top (All, Fetch/XHR, JS, CSS, Img, Media, Font) narrow the list to a specific resource type. Clicking “Img” shows only images — the fastest way to identify the largest images without scanning hundreds of mixed entries.
The summary bar at the bottom gives instant overview statistics: total requests, total data transferred, DOMContentLoaded time, and Load time. These numbers tell the story at a glance. A page with 200 requests, 4MB transferred, and a 7-second Load time has significant performance issues. A page with 28 requests, 400KB, and 1.1 seconds is well-optimised. Anyone with Chrome can audit any publicly accessible page’s performance profile within two minutes of learning these basics — no special software or account needed.
Device Mode — simulating mobile screens on a desktop
Device Mode simulates how a webpage appears at different screen dimensions — phone screens, tablet screens, any custom dimensions — without needing a physical device or a separate mobile browser. This is the fastest way to verify how a website looks on mobile devices your visitors actually use.
To open: click the device icon in the DevTools toolbar (the phone-overlapping-tablet outline near the left end), or press Ctrl+Shift+M while DevTools is open. The browser viewport switches to a constrained mobile simulation with a device selector bar at the top. The dropdown lists preset profiles: iPhone 14 Pro, iPhone SE, Pixel 7, Galaxy S8+, iPad Air, and dozens more — each profile sets the correct screen width, height, device pixel ratio, and user agent string.
The Throttling dropdown within Device Mode simulates mobile network conditions alongside screen simulation — “Fast 3G,” “Slow 3G,” and “Offline.” Combined with the Network panel open at the same time, this shows exactly which resources block the page from becoming usable on a typical mobile connection. Setting Slow 3G and reloading while watching the Network panel Waterfall is the most revealing combination for understanding real-world mobile page performance — because what loads fine on a fast desktop connection often becomes genuinely unusable on 3G throttling.
The rotate button flips between portrait and landscape orientations. Responsive design breakpoints failing in landscape is a surprisingly common issue — a site that looks correct in portrait mobile view can completely break when rotated. Device Mode makes this visible in seconds.
The Console and Lighthouse — quick diagnostics and automated audits
The Console panel is the browser’s primary error-reporting surface. Every JavaScript error on the page appears as a red entry with a description, the file name, and the line number. For anyone investigating why a page feature isn’t working — a button that does nothing when clicked, a form that submits with no visible response, a gallery that fails to load — the Console almost always contains a red error message identifying the exact failure. Open DevTools, click Console, reproduce the broken behaviour, and read what appears. The error message usually names the specific script responsible, which is everything you need to report the problem accurately or search for a specific fix.
Several Console commands are useful without any programming background:
copy(document.body.innerText)— copies all visible text from the current page to the clipboard. Useful for pages where normal copy-paste is disabled or where text is spread across many elements that would require individual selection.document.querySelectorAll('img').length— returns the number of images on the current page. Quick check for pages suspected of loading too many images.document.title— returns the page’s title exactly as search engines see it in the title tag. Useful when the visible heading differs from the actual title tag and you want to verify what’s actually there.
Lighthouse generates automated quality reports for any webpage across four categories: Performance, Accessibility, Best Practices, and SEO. Each category gets a score from 0 to 100 based on automated checks, and the report lists specific, prioritised recommendations. Access it from the Lighthouse tab in the DevTools panel → select audit categories → “Analyze page load.” The resulting report identifies oversized images, render-blocking resources, missing accessibility attributes, missing meta descriptions, and dozens of specific technical issues.
For website owners who aren’t developers but want an honest technical assessment of their site’s health: the Lighthouse report is the most accessible diagnostic available. No account, no third-party tool, no fee. Our guide on Chrome performance covers browser-side speed improvements that complement what DevTools reveals about page-level performance, and our Chrome extensions guide covers developer-focused extensions that pair with DevTools for more advanced site analysis. For the full DevTools documentation beyond what’s covered here, the Chrome developer documentation covers every panel in technical detail, including the Sources debugger, Memory profiler, and Performance timeline.
Practical use cases that don’t require developer knowledge
To be concrete about who this is useful for beyond developers:
- Content managers and SEOs: Lighthouse for SEO audits, Elements panel for checking meta tags and title tags, Network panel for identifying slow-loading pages before publishing
- Designers reviewing implementations: Elements panel for verifying exact colours, fonts, and spacing match the design spec; Device Mode for mobile visual QA
- Site owners without technical staff: Lighthouse for a prioritised punch list of things a developer should fix; Network panel for identifying the largest files on key pages
- Anyone troubleshooting a broken site feature: Console for the specific error message, which makes communicating the problem to a developer much more precise than “the thing doesn’t work”
- Journalists and researchers: Elements panel and Console for accessing content behind restrictions, extracting text, verifying what’s really on a page versus what’s displayed
The instinct with Chrome DevTools is to assume it’s only for developers and skip it. The reality is that five specific features — the element inspector, colour identification, the Lighthouse report, Device Mode, and Console error reading — are immediately useful to a much broader group of people than the “developer tools” label suggests. None of them require writing any code; they require only knowing where to click and what to read.
Sources panel — the basics worth knowing
The Sources panel shows all the files a page loads — HTML, JavaScript, CSS, and other resources — as a navigable file tree. For non-developers, the most useful function is viewing the source of any specific file rather than the compiled, minified version that View Source often shows. Navigate Sources → Page → the website’s domain → find any specific script or stylesheet to see its content.
JavaScript files on production websites are almost always minified — compressed into a single unreadable line. The pretty-print button at the bottom of the Sources panel (the {} icon) reformats minified code into readable, indented format. This doesn’t help execute or understand complex code, but it makes it possible to read and search through script content — useful for verifying what a third-party script actually does when you’re evaluating whether to install it on your site.
Application panel — checking what a site stores on your device
The Application panel shows everything a website has stored on your device: cookies (by domain, with name, value, and expiry date), localStorage and sessionStorage values, IndexedDB databases, cached files via Service Workers, and more. For privacy investigation: the Cookies section shows exactly which tracking cookies a site has placed, which domains set them, and how long they persist.
The Storage section shows how much space a site’s cached content is consuming locally. Sites using Service Workers for offline functionality cache significant amounts of data — the Application panel shows the exact size and allows clearing it selectively per site without clearing all Chrome data globally. This is more targeted than the standard “clear browsing data” flow when a specific site is caching outdated content and you want to reset only that site’s cached state.
Keyboard shortcuts worth remembering
| Shortcut | Action |
| F12 | Open/close DevTools |
| Ctrl+Shift+C | Open DevTools with element inspector active |
| Ctrl+Shift+M | Toggle Device Mode |
| Ctrl+R (while DevTools open) | Reload page and capture in Network panel |
| Esc (in any panel) | Toggle Console drawer at bottom |
| Ctrl+F (in Elements) | Search within the HTML tree |
| Ctrl+G (in Sources) | Go to specific line number |
| Ctrl+P (in DevTools) | Open any file from the page by name |
The Console drawer (toggle with Esc from any panel) is worth knowing: it keeps the Console visible alongside any other panel without switching away from Elements or Network. This means you can watch for Console errors while inspecting Network requests, or monitor JavaScript output while examining HTML structure — both panels active simultaneously in the same DevTools view. Related: Chrome Startup Settings.
Chrome DevTools is one of those tools where every hour of learning produces compounding practical returns. The first 30 minutes of familiarisation with the element inspector and Network panel alone give you capabilities that previously required either specialist knowledge or dedicated third-party software. The full depth extends into professional web development territory, but the entry level is accessible to anyone willing to press F12 and spend some time exploring what appears. If this sounds familiar, Chrome Pinned Tabs is worth a look.
