How to Debug Websites with Safari Developer Tools

To debug a website in Safari, enable Safari’s developer features, open Web Inspector, and choose the panel that matches the symptom. Use Elements for rendered HTML and styles, Console and Sources for JavaScript, Network for failed or slow resources, and Timelines for performance activity. For a layout defect, reproduce the affected viewport in Responsive Design Mode, then inspect the element and its styles.

Apple’s Web Inspector documentation describes the tool as the place to inspect and debug HTML, CSS, and JavaScript. The workflow below helps you gather evidence before changing source code.

1. Enable Safari’s developer tools

1. Open Safari settings and enable the features for web developers. The setting’s location and label can vary by Safari release.
2. Confirm that Develop appears in Safari’s menu bar.
3. Open the page you want to investigate.
4. Choose Develop > Show Web Inspector. This opens the last-used inspector tab. Choose Develop > Show JavaScript Console to go straight to Console.

If the menu or setting is named differently in your release, consult Safari Help for the installed version. Apple documents the developer menu and its entry points in the Develop menu reference.

2. Choose the panel that fits the symptom

Start with the narrowest panel that can provide evidence. A missing image, for example, is usually better investigated in Network than by searching through unrelated panels.

Symptom	Start here	What to look for
Text, an element, or styling is wrong	Elements	The rendered DOM, selected node, and styles applied to it.
A click or interaction does nothing	Console, then Sources	Errors or warnings, then the script and execution path involved.
An image, script, stylesheet, or API call is missing	Network	The request’s status, response, and timing.
The page is slow, janky, or doing unexpected work	Timelines	Requests, JavaScript events, layout, rendering, CPU, and memory activity.
Layout breaks at a particular screen size	Responsive Design Mode and Elements	The affected viewport, selected element, and its styles.
State or stored data seems wrong	Storage	Relevant site storage and persisted state.

Web Inspector also has specialized views such as Graphics, Layers, and Audit. Begin with the panel tied to the symptom, then use specialized views if the evidence points there. Apple’s Web Inspector documentation describes the principal panels.

3. Inspect rendered HTML and CSS

1. Open Elements and locate the visible element in the rendered DOM.
2. Select it and inspect the styles applied to it. Check whether a rule is overridden, a selector does not match, or a parent’s layout affects the result.
3. Temporarily edit a style in Web Inspector to test a hypothesis. For example, changing a width or display rule can show whether that rule causes the visible problem.
4. Once the cause is clearer, make the durable change in the site’s source files and reload to verify it.

Inspector edits are diagnostic changes to the current page state. Treat them as experiments, not as saved edits to your project.

4. Debug JavaScript and interactions

1. Open Console and reproduce the interaction. Check for errors and warnings that appear at the time it fails.
2. Read the message and its source location. Follow the relevant script into Sources to examine the code path.
3. Use Console’s interactive JavaScript prompt to inspect values or run a small diagnostic expression in the page context.
4. Form a specific hypothesis, such as a missing event handler or an unexpected value, then reproduce the issue again to see whether the evidence supports it.

A clean Console does not prove an interaction is correct. The failure may depend on state, timing, input, or a request that has not yet been checked. Pair runtime inspection with Network when an interaction depends on an API or other resource.

5. Find failed or slow requests

1. Open Network before reproducing the problem so the relevant activity is visible.
2. Repeat the page action that triggers the missing asset or API call.
3. Inspect the request’s status, response, and timing.
4. Use the failing resource or response as a lead back to the responsible application code or server behavior.

A resource that never appears, returns an unexpected response, or takes unusually long can each explain a visible symptom. Compare requests around the failure instead of assuming that the first error in the page is the cause.

6. Investigate slow rendering and jank

Use Timelines to record activity while reproducing the slow or janky behavior. Correlate requests, JavaScript events, layout, rendering, CPU, and memory-related activity. A recording helps test a hypothesis; a visual slowdown alone does not establish its root cause.

1. Open Timelines and begin a recording.
2. Perform the smallest repeatable action that shows the slowdown.
3. Stop the recording and inspect activity around that moment.
4. Use the sequence of events to decide whether to investigate requests, JavaScript, layout, rendering, or memory further.

Keep the reproduction consistent when comparing recordings. Avoid drawing conclusions from activity that does not line up with the reported delay.

7. Reproduce responsive layout problems

1. Choose Develop > Enter Responsive Design Mode. Apple documents Control-Command-R as a shortcut; check Safari Help if it differs on your release or keyboard.
2. Set the viewport near the width and height where the defect occurs.
3. Account for display pixel ratio when investigating a high-density screen.
4. Keep Web Inspector available, select the affected element, and examine its styles while changing the viewport.
5. When device-specific behavior matters, confirm the result on the actual target device as well.

Responsive Design Mode previews viewport and display pixel ratio changes. It is a diagnostic aid, not a guarantee that every real device behavior is reproduced. See Apple’s Responsive Design Mode documentation.

8. Inspect a website on an iPhone or another target

Safari can inspect eligible content on connected devices, simulators, and apps. Availability depends on the target and its configuration.

1. Connect and configure the target device, simulator, or app so its web content is eligible for inspection.
2. On the Mac, choose Develop > Inspect Apps and Devices.
3. Choose the eligible target or page to open its inspector.
4. Reproduce the issue on that target and inspect the relevant panel just as you would for a desktop page.

Apple documents eligible iPhone and iPad targets, simulators, and apps. A wired-paired device can be configured for network connection when it and the Mac share a network. Service workers are listed separately because they are shared across webpages. Check the target’s configuration and Apple’s Inspect Apps and Devices documentation if it does not appear.

9. Troubleshooting common problems

Problem	Likely cause	What to do
Develop is missing	Developer features are not enabled, or the setting differs in this Safari release.	Enable web developer features in Safari settings, then consult Safari Help for the installed version if the label differs.
Web Inspector opens on an unexpected tab	Show Web Inspector reopens the last-used inspector tab.	Select the needed panel directly, or use Show JavaScript Console to open Console.
The element looks correct in the source but wrong in the page	The rendered DOM or applied styles differ from the source you expected.	Inspect the live node and its computed/applied styles in Elements; check parent layout and overridden rules.
There is no obvious JavaScript error	The failure may depend on timing, state, or a resource rather than an uncaught error.	Reproduce with Console open, inspect the script in Sources, and check related Network requests.
A request is missing or fails	The resource did not load successfully, returned an unexpected response, or was delayed.	Reproduce with Network open and inspect status, response, and timing to trace the failure.
The device does not appear in the Develop menu	The target may not be eligible or configured for inspection.	Check device, app, simulator, and connection configuration; consult Apple’s device inspection guide.
The responsive preview does not match the phone	Viewport simulation cannot establish all target-device behavior.	Check viewport and pixel ratio, then reproduce on the actual device for device-specific issues.
The keyboard shortcut does not work	Shortcut behavior can vary with Safari version or keyboard configuration.	Use the Develop menu entry and verify the shortcut in local Safari Help.

10. A repeatable debugging checklist

• Reproduce the symptom and note the page state and viewport.
• Choose the panel that matches the symptom.
• Gather evidence before editing source code.
• Test one hypothesis at a time with a temporary inspector change or a focused reproduction.
• Make the fix in project source and repeat the same reproduction.
• Check a real target device when the issue depends on device behavior.

Or skip the browser setup

If you need a screenshot for a visual check, ScreenshotNeo is a website screenshot API and MCP server. A screenshot can document the page appearance, though it does not replace Web Inspector for examining DOM, JavaScript, or network activity. The API documentation covers the request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers indicate the page verdict and billing status. An MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Sign up for 1,000 free screenshots a month, with no card.

FAQ

Can Safari Developer Tools debug a live website?

Yes. Web Inspector examines the page open in Safari, including its rendered structure, styles, scripts, and resource requests. Changes made in the inspector are useful for diagnosis; make lasting fixes in your project source.

Can I automate Safari tests with Web Inspector?

Web Inspector is for interactive inspection and debugging. Apple documents WebDriver as a separate route for automating Safari tests; it complements the debugging workflow.

Does Responsive Design Mode replace testing on an iPhone?

No. It helps investigate viewport and display pixel ratio behavior. Check the actual target when the defect may depend on device-specific behavior.

Why are service workers listed separately?

Service workers are shared across webpages, so Safari presents them separately from individual page targets.