The Elements tab
The Elements tab shows the page in its current state: what each element on the screen actually is in the markup, and how that markup behaves as the viewport narrows.
What the DOM is
DOM stands for Document Object Model. It is the structure of the page that the browser builds from the HTML and can then modify with scripts. The HTML originally returned by the server is a separate artefact, visible in the Network tab on the document request. If a value appears in Elements but not in the source HTML, it was inserted by a script.
Locating an element
The arrow icon in the top-left corner of DevTools (ctrl shift c / cmd shift c) selects an element on the page and highlights it in the markup. ctrl f / cmd f inside the Elements tree searches by text, CSS selector or XPath — the same selectors used by automated tests, which is why locator uniqueness is verified here.
CSS: how an element looks
CSS stands for Cascading Style Sheets. It is the language used to describe how a web page looks. HTML describes the structure and meaning of a page; CSS describes its colour, font, size, spacing, borders and position. CSS rules usually live in stylesheet files, but can also be written directly on an element in its style attribute.
button { background-color: #f28338; padding: 12px; }
The selector button chooses all buttons. background-color and padding are properties; the values after the colon set their appearance.
“Cascading” means that several rules can try to set the same property. The browser chooses one final value, usually from the more specific rule or the one written later. To inspect CSS, select an element in Elements.
The Styles pane lists matching rules, their source file and rules that were overridden. The Computed pane shows the final value the browser actually uses. Crossed-out declarations do not apply because another rule won.
Colours and fonts: one colour may be written as #f28338, rgb(242, 131, 56) or hsl(...); these are formats, not different colours. Click the colour square in Styles to inspect it or switch its format. font-family can list fallbacks: the browser uses the first installed font. To confirm the font actually drawn, open Computed and find Rendered Fonts at the bottom.
Five common tags
HTML describes what is on a page, not just how it looks. These five tags are a useful starting point:
<button>Save</button> — performs an action: saves, sends or opens something. It receives keyboard focus and works with Enter and Space.
<a href="/profile">Profile</a> — takes the user to another page or a location on the current page.
<label for="email">Email</label> — names a form field and connects to <input id="email">.
<img src="photo.jpg" alt="Team meeting"> — inserts an image; alt describes meaningful content for a screen reader.
<nav>...</nav> — marks a group of navigation links, such as the main menu.
A styled <div> can look like a button without being one. The difference is visible in the markup and matters to keyboards, screen readers and browser behaviour.
Headings: h1, h2 and h3
Headings describe the structure of a document. <h1> is its main topic, <h2> is a section of that topic, and <h3> is a subsection inside an <h2>.
<h1>Learning DevTools</h1>
<h2>Elements tab</h2>
<h3>Finding an element</h3>
Use one <h1> per page and do not skip levels: after an <h2> comes an <h3> only when it introduces a subsection. A heading is not a way to make text bigger; use CSS for size and a heading tag for structure.
What to check in the markup
- Whether a control is a real <button> or a <div>. Only the former receives keyboard focus: navigate the page with Tab and note which controls are skipped.
- Whether each input is associated with a <label>. If it is, clicking the caption focuses the field; if not, a screen reader has no name to announce.
- Exactly one <h1> and headings in sequential order, without skipping from <h2> to <h5>.
- Whether images have a meaningful alt attribute, and decorative images an empty one.
Checking screen sizes
Responsive layout is a page layout that adapts to the available screen width. The same site should remain usable on a narrow phone, a tablet and a wide desktop screen.
Mobile layout is the version of that layout for small screens: columns often become one column, the menu changes, controls become easier to tap and text must not run beyond the edge.
This matters because a page that looks correct on a developer’s laptop can be unusable on a phone: buttons may be off-screen, a form may require horizontal scrolling or a menu may cover the content. Checking only one desktop width misses these defects.
The device toolbar (ctrl shift m / cmd shift m) sets an arbitrary viewport width. Testing is organised around breakpoints — the widths at which the layout changes — rather than device names: approximately 360, 768, 1024 and 1280, plus a few pixels on either side of each transition. At every width, check that columns collapse as expected, text does not overflow, controls remain visible and the page does not gain horizontal scrolling. Rotation and browser zoom at 200% are two further cases to cover.
Edits are local
Elements lets you temporarily change what you see in your browser. You can edit text, delete an element or change a CSS value to test an idea. These are local edits: they do not change the site for other people or send anything to the server. Reloading the page cancels all of them.
Why do this? To check a possible cause of a defect before writing a report. For example, change a short product name to a very long one to see whether the card breaks; hide an advertisement to see whether it covers a button; or temporarily change a colour or spacing to show a developer the expected result.
To change text: select it on the page, right-click → Inspect, then double-click the text between the opening and closing tags in Elements. Type a new value and press Enter.
To change a style: select the element, find the Styles pane and change a value such as color or margin. The page updates immediately.
To remove an element: select its tag in Elements and press Delete. Reload when you want it back.
At the interview
What is checked here is whether markup can be read and used to verify an interface. Try answering before opening the answer.
juniorentry-level knowledge
1. How do you find an element quickly, on the page and in the markup?
Press ctrl shift c / cmd shift c and click the element on the page: DevTools selects it in Elements. Inside the tree, ctrl f / cmd f opens a search that accepts text, a CSS selector or an XPath.
2. Can you fix text or CSS in the Elements tab?
Yes, but only locally, in your own browser: text, a CSS property or a whole element can be changed or removed to test a hypothesis. The changes never reach the server, no one else sees them, and they disappear on reload.
3. How do you check a responsive layout in DevTools?
Open the device toolbar with ctrl shift m / cmd shift m and walk the page through different widths, especially around the breakpoints. What to confirm: nothing runs off the screen, every control stays reachable, columns rearrange as expected and no horizontal scrollbar appears.
middlea more advanced level
4. How does the DOM in the Elements tab differ from the source HTML?
Elements shows the current DOM tree, after the browser has built the page and JavaScript may have altered it. The source HTML is the document the server returned. If a value is in the DOM but absent from the source HTML, a script put it there.
5. Why can a button built from a div be a defect?
A styled <div> can look like a button while getting none of the standard semantics, focus or keyboard handling. An action needs a <button>, or the developer has to implement every missing property by hand.
Questions on the other topics are collected on the QA interview questions on DevTools page.