How to See What JavaScript Is Doing on a Web Page
Use your browser’s Console to find JavaScript messages and errors, then set debugger breakpoints to trace execution and inspect values.
To see what JavaScript is doing on a web page, open the browser’s developer tools. Start in the Console to read messages and errors or evaluate a quick expression. To follow execution, set a breakpoint in the debugger, reproduce the action, and inspect values while the code is paused. If the problem is an unexpected request, inspect it in Network and trace the initiating Fetch or AJAX code with a breakpoint.
1. Start with the Console
The Console is the quickest way to check what page scripts report and to evaluate a small expression in the page context. In Chrome, open it with Command+Option+J on Mac, or Control+Shift+J on Windows, Linux, and ChromeOS. Shortcuts and menus can vary by browser version and platform. Chrome DevTools overview
- Open the page that has the behavior you want to understand.
- Open developer tools and select the Console panel.
- Reload the page or repeat the action that triggers the problem.
- Read errors, warnings, and logged messages. Select a message’s source link when available to jump to the relevant script location.
- For a quick check, type a small expression at the Console prompt and press Enter. For example,
location.hrefshows the current page URL, anddocument.titleshows its title.
Firefox calls its page-level panel the Web Console. It can show page-associated network requests, JavaScript and CSS errors, security warnings, and messages logged by page scripts. Firefox Web Console documentation
A Console error is evidence of a reported problem, but it may not explain the full sequence that caused it. Use the debugger when you need to inspect execution and variable state.
2. Pause execution with a breakpoint
A breakpoint pauses JavaScript at a selected point so you can inspect the current function’s values and step through what runs next. In Chrome:
- Open DevTools and select Sources.
- Find the script associated with the behavior. If the file is unfamiliar or minified, use the source navigation and filtering features to locate relevant code.
- Click a line number to set a breakpoint. Choose a line that runs before or during the behavior you want to investigate.
- Return to the page and repeat the action, such as clicking a button.
- When execution pauses, inspect local variables and the call stack. Step over a line to continue within the current function, or step into a function to follow a call.
- Use the Console while paused to query values in the current execution context.
Debugger stepping can still help with minified code. For details on pausing, inspecting values, and querying the Console while paused, see the Chrome JavaScript debugging reference.
3. Trace a request with Network and the debugger
If a click or form submission sends an unexpected request, use the Network panel to identify the request, then trace the code that initiates it:
- Open DevTools’ Network panel and reproduce the action.
- Find the request that looks incorrect and inspect its URL, method, and available request details.
- Open the Sources debugger and set a breakpoint in the likely Fetch or AJAX code, or use the debugger’s request-related breakpoint facilities where available.
- Repeat the action. When execution pauses, inspect the call stack and values used to construct the request.
- Step through the code to find where the URL, parameters, or request conditions change.
Chrome documents using a breakpoint to trace the code that triggers an AJAX or Fetch request. See its breakpoints guide.
4. Choose the view that matches the question
| What you need to find out | Start here | What to do |
|---|---|---|
| Did a script report an error or log a message? | Console or Firefox Web Console | Reload or repeat the action, then inspect errors, warnings, and messages. |
| What code runs when I take an action? | Sources / debugger | Set a breakpoint, reproduce the action, and step through execution. |
| Why did the page send this request? | Network plus debugger | Inspect the request, then trace the Fetch or AJAX code that initiated it. |
| What is the value of something right now? | Console, often while paused | Evaluate a small expression in the page or paused execution context. |
5. Common problems and fixes
| Symptom | Likely cause | What to try |
|---|---|---|
| No messages appear | The page may not log anything, the relevant action has not happened, or Console filters may hide messages. | Reload and reproduce the action. Check Console filters and confirm you are inspecting the correct page context. |
| The error points to minified or hard-to-read code | The delivered script is compressed or generated. | Use debugger source navigation and filtering to find the relevant code, then set a breakpoint and step through it. Debugger stepping can work with minified code. |
| A breakpoint never pauses | The selected line may not run, the action may take another code path, or the script may not be loaded in the context you are inspecting. | Confirm the correct script and page context, choose a line on the active path, and reproduce the action after setting the breakpoint. |
| The request is visible but its cause is unclear | Network shows the request, while the code path that creates it may be elsewhere. | Use a breakpoint on the relevant Fetch or AJAX path and inspect the call stack and values when execution pauses. |
| The shortcut does not open the Console | Shortcuts differ across browsers, operating systems, and versions. | Open developer tools from the browser menu and select Console. In Chrome, the documented shortcuts are Command+Option+J on Mac and Control+Shift+J on Windows, Linux, and ChromeOS. |
6. Keep the investigation focused
- First reproduce the behavior reliably; a breakpoint only helps if execution reaches it.
- Start with one question: a reported error, a code path, a current value, or a request.
- Use the Console for a quick check, and switch to breakpoints when you need execution order or local state.
- When investigating a request, connect the Network evidence to the code that initiated it instead of guessing from the URL alone.
- Browser panel names, menus, and shortcuts vary. The steps and shortcuts here are grounded in Chrome and Firefox documentation; check your browser’s own documentation for exact instructions elsewhere.
7. Or skip the browser setup
If the goal is a clean visual record of a page rather than tracing its JavaScript execution, ScreenshotNeo captures a URL as an image or PDF with one API request. It does not show JavaScript variables, logs, or call stacks; use browser developer tools for those.
For example, save a screenshot with cURL:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
See the ScreenshotNeo API documentation for options and configuration. The same request in Python:
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)
And in Node.js:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);
Cookie banners are accepted and removed before capture, along with known newsletter popups and chat widgets. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use screenshot and PDF capture tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month.
FAQ
Can I see JavaScript errors without changing the site?
Yes. Open the browser’s developer tools and inspect the Console or Web Console while loading the page or reproducing the behavior.
How do I find what code runs when I click a button?
Set a breakpoint in the likely script, click the button, and inspect the paused execution, values, and call stack.
Can a screenshot tell me what a script did?
A screenshot records the rendered page. It does not expose JavaScript logs, variable values, or execution flow; use the Console and debugger for those.


