How to Check Website Network Requests in Chrome, Firefox, Edge and Safari

To see what a website sends and receives, open your browser’s developer tools, choose Network, reload the page, and then use the website while watching the request list. Select a request to inspect its destination and any data sent with it. You do not need to write code or install an extension.

This guide covers the desktop versions of Chrome, Firefox, Microsoft Edge, and Safari. It also explains how to check a tool that says it runs locally in your browser, including the tools on Web2Generators.

Jump to your browser

• Google Chrome
• Mozilla Firefox
• Microsoft Edge
• Safari on Mac
• Other browsers and mobile devices
• Try a local-processing check

What is a network request?

A network request is a message from your browser asking a server for something or sending information to it. Opening a website normally requests its HTML, stylesheets, scripts, fonts, and images. Further requests may load search results, submit a form, or upload a file.

A website making requests does not automatically mean it uploads the text you type. A local tool first downloads the code it needs, then can process your input on your device. The useful question is whether using the tool transmits your input or results.

For the parts of a request, including URLs, headers, and bodies, see MDN’s HTTP messages guide .

The Network panel shows activity associated with the inspected page. It is not a monitor of every connection made by your computer.

Before you start

Use harmless sample data, such as network-check-123, instead of a real password or private document. Open the developer tools before the action you want to investigate. Requests made earlier may be missing from the log.

Start with all request types visible and remove any text filters. If recording can be paused, make sure it is running. Keep logs across navigation when testing an action that redirects or reloads the page.

Check network requests in Google Chrome

1. Open the website. Right-click the page and choose Inspect to open DevTools.
2. Select Network. If the tab is hidden, look in the tab overflow menu.
3. Make sure recording is enabled and select All. Enable Preserve log if your test includes navigation.
4. Reload the page to capture its initial requests. Then type sample input or click the control you want to test.
5. Select a request. Headers shows its URL and method; Payload, when present, shows submitted data or query parameters. Response shows what came back from the server.

The Fetch/XHR filter helps locate API calls, but return to All for a broader check. Data can also travel through other request types. For an existing WebSocket connection, inspect its Messages tab.

See Google’s Network features reference  for details about recording, filters, and request inspection.

Check network requests in Mozilla Firefox

1. Open the website and press Ctrl + Shift + E on Windows/Linux, or Command + Option + E on macOS. This opens the Network Monitor directly.
2. Select All and remove any search filter.
3. Reload the page, then perform the action you want to check.
4. Select a request. Look at Headers for the destination and method, Request for submitted data, and Response for the returned content. WebSocket entries have a Messages view.
5. For a test involving page navigation, enable Persist Logs in the Network Monitor’s settings. Wording can vary by Firefox version.

Firefox documents opening the Network Monitor , reading request details , and preserving the request list .

Check network requests in Microsoft Edge

1. Open the website. Right-click the page and choose Inspect.
2. Select Network in DevTools. Use the overflow menu if it is not visible.
3. Check that recording is active, clear filters, and choose All.
4. Reload the page. Enable Preserve log if you need to follow requests through a reload or redirect.
5. Use the website with sample data, then select a request. Check Headers for its URL, Payload for outgoing data, and Response for incoming content.

Edge’s developer tools are similar to Chrome’s, so the same distinction between page-loading requests and action-triggered requests applies. A successful status such as 200 describes the HTTP response; it does not certify a request as private or safe.

Microsoft’s Inspect network activity guide  walks through the Network tool.

Check network requests in Safari on Mac

Safari may need a one-time setup before its developer tools appear:

1. Open Safari → Settings → Advanced.
2. Enable Show features for web developers. Older versions call this Show Develop menu in menu bar.
3. Open the website, then choose Develop → Show Web Inspector, or press Command + Option + I.
4. Select Network, remove filters, and reload the page.
5. Perform your test action and select any resulting request. Inspect the URL, method, and request headers in Headers, and any available request body. Preview shows the returned resource. Enable Preserve Log when following navigation.

If you want to observe a fresh resource download, Safari’s Ignore Cache option bypasses the normal resource cache while Web Inspector is open. Turn it off afterward if you enabled it for this test.

See WebKit’s instructions for enabling Web Inspector  and its Network tab reference .

Check whether an online tool sends your input

Try this with our HTML entities encoder and decoder:

1. Open Network, select All, and reload the tool page. Let the initial loading finish.
2. Keep recording active. Note the existing requests so you can distinguish later activity; if there are no persistent connections to inspect, you can clear the list for a simpler view.
3. Enter a recognizable, harmless sample such as <p>network-check-123</p>. Convert it, change it, and convert it again.
4. Watch for new requests while typing and converting, and for a short time afterward. On a site with a WebSocket connection, also watch outgoing messages on that connection.
5. Inspect any activity around those actions. Check the destination, URL parameters, and outgoing body for your sample text or a transformed version of it.

On Web2Generators tools marked with the privacy icon, the tool inputs and generated results are processed locally and are not uploaded. The site still needs normal requests to load its pages and assets. The production site also loads Google Tag Manager and AdSense, so you may see requests associated with website measurement and advertising. The tool code does not add entered data or generated results to the analytics data layer or advertising APIs; inspect request contents rather than assuming that every Google request contains your sample. For example, the htpasswd generator may download its background-worker script when hashing starts. Downloading that code is different from sending a password to a server.

Click the privacy icon in any local tool’s header for this explanation and a link back to this guide. You can also read our privacy policy.

How to interpret what you find

Inspect outgoing data when checking for uploads. Finding your sample in a response means the server returned it; the request tells you what the browser sent.

For the request-body and header views used in this comparison, see Firefox’s request details reference .

An empty log is evidence about the actions you observed, not a universal privacy guarantee. Filters, paused recording, delayed transmissions, service workers, or a different execution context can affect what you see. Encoded or encrypted application data may not contain your sample as readable text. A clean observation does not rule out local storage or later transmission.

As a supplementary check, load the tool, disconnect from the internet, and repeat the action without reloading. Continued operation supports the conclusion that processing can happen locally. It does not prove that a site never queues data to send when the connection returns.

Other browsers and mobile devices

Desktop browsers based on Chromium, such as Brave, Opera, and Vivaldi, generally offer a similar Inspect → Network workflow. Firefox-based browsers often provide a comparable Network Monitor. Menus, shortcuts, and available features may differ; start with the browser’s developer-tools menu. For example, Vivaldi documents Tools → Developer Tools in its developer tools guide .

Phone and tablet browsers usually do not expose the full desktop panel directly. Safari on iPhone or iPad can be inspected from Safari on a connected Mac after enabling Web Inspector on both devices. Apple explains the setup in Inspecting iOS and iPadOS .

Frequently asked questions

Does HTTPS prevent me from inspecting requests?

No. HTTPS encrypts traffic between the browser and server, but your own browser can display the requests it creates and the responses it receives. A website may additionally encode or encrypt a payload, making its contents harder to interpret.

Why is the Network panel empty?

Reload with the developer tools open, confirm recording is active, and remove filters. If requests appear during loading but no new activity appears while using a tool, the action may run locally. Check persistent connections and the limitations above before drawing a conclusion.

Can I share the network log with someone?

Browsers can export network captures as HAR files. These can contain sensitive URLs, request bodies, cookies, or tokens. Use dummy data and review a capture before sharing it; do not assume an export removes every secret. For Chrome’s export options, see its HAR export documentation .