Legal document
HTTP Monitor does not collect, transmit or sell information. Everything it processes stays in the browser where it is installed, and the author has no way of reaching it.
The rest of this document exists because an extension that intercepts traffic sees sensitive things, and you should know exactly what it sees, where that stays and how long it lasts.
HTTP Monitor is developed and published by Jesús Andrés Correal Ortiz, an independent developer based in Colombia. For anything related to this policy: jesusandrescorreal@gmail.com.
The tool's job is to show you — and let you modify — the HTTP requests a page makes, which by definition requires being able to read them. That is not a side effect of the design; it is what the tool does.
You decide the scope. The extension ships with scope restricted: until you add a site to the list, it acts on no page at all. It also intercepts nothing while the master switch is off.
Within the sites you enable, the extension can read and store locally: the full URL, the method, request and response headers — including authorization headers and any cookies the browser sends — the request body, the response body, the status code and timestamps.
| What | Where it is stored | How long it lasts |
|---|---|---|
| Rules, profiles, variables and settings | The extension's local storage, on your machine | Until you delete them or uninstall the extension |
| Captured calls, bodies included | The browser's internal database (IndexedDB), on your machine | Cleared when you close the tab, press "Clear", or hit the per-tab ceiling |
| Requests you compose by hand | The extension's local storage | Until you delete them |
| Which tabs have deep mode attached | The browser's session storage | Cleared when the browser closes |
| Interface and theme preferences | The extension's local storage | Until you uninstall the extension |
One detail worth knowing: a tab's captured calls are deleted when you close that tab. This is not a pending limitation, it is deliberate — a log that outlives the tab that produced it is a log nobody will look at again and one that can still leak. If you need to keep it, export the HAR file before closing.
The only network requests the extension originates are the ones you trigger explicitly: replaying a captured call, or sending a request you composed. They go to the destination you typed and nowhere else.
When you inspect real traffic, credentials, session tokens, cookies and personal data from your application's responses will appear on screen. The extension shows them because that is why you opened it, and it always handles them on your machine: it decodes tokens locally to show you what is inside, and flags personal data in bodies to warn you, without sending anything anywhere to do either.
The practical consequence is yours: be careful with screen sharing and with the files you export. A HAR of a real session contains authorization headers exactly as they travelled.
| Permission | Use |
|---|---|
| Access to websites | Reading and modifying requests on the pages you enable. It is broad because there is no way to know in advance which environment you work in: a local one, a staging one, or your own company's. |
| Storage and unlimited storage | Keeping the configuration and the captures. The second one is needed because the response bodies of a debugging session run into tens of megabytes. |
| Tabs | Identifying the active tab and its address, so you are shown what belongs to that tab. |
| Side panel | Showing the interface when you click the extension's icon. |
| Declarative network rules | Applying headers, domain blocks and redirects at the network layer. |
| Request observation | Reading the real headers that went over the wire. Read-only. |
| Script injection | Showing the floating panel over the intercepted page. |
| Debugger | Deep mode, and nothing else. It is the only browser interface that hands over the real body of a response. See the next section. |
| Clipboard | Copying captures, headers and rules, and pasting a shared rule. |
Deep mode attaches the browser's debugger to one tab in order to reach what the other layers cannot see: the navigation itself, every subresource of every frame, service worker traffic, and the real response bodies of all of it.
That permission shows up at install time, and we know it is the most intimidating warning an extension can display — so here is the full argument rather than one line. Reading the real body of a response the extension did not itself originate is only possible through the debugger. No other browser interface allows it: the request-observation one hands over headers but never content, and the network-rules one cannot see bodies at all. Without that permission, whatever a navigation, a subresource or a service worker returned is simply out of reach — which is exactly what you need to look at when debugging a progressive web app or a server-rendered page.
And even so: it never attaches on its own. You switch it on, tab by tab, from the settings. It detaches when you switch it off, when you close the tab, or when the browser ends the session, and for as long as it lasts the browser shows its own notice that the tab is being debugged. Nothing it reads leaves your machine.
The permission cannot be requested later, only at install time: the browser does not allow the debugger permission among those an extension asks for at the moment of use. Its presence in the list does not mean it is in use — until you switch it on, no debugging session is open.
Rules accept a script and debugging hooks, written by you, which run inside the intercepted page to decide what to answer. That code is yours: it is sent nowhere, it is stored with the rule on your machine, and it only runs on the pages you enabled. Because it runs in the page's context it can read what the page sees — treat it with the same judgement you would apply to a snippet pasted into the browser console.
The extension can write files you download to your machine: a HAR of the captures, a Postman collection and the full configuration. It builds them locally and hands them to the browser's download manager; it uploads them nowhere.
When exporting the configuration, values marked as secret are replaced with a placeholder before the file is written, so sharing a scenario does not mean sharing a credential. Exporting captures does not do that substitution: a HAR is a faithful record of what happened, authorization headers included. Share it with that in mind.
This is a software development tool and it is not directed at children under 13. No information from children is knowingly requested or processed.
The site you are reading is static: no cookies, no analytics, no third-party resources and no forms. The only thing it stores in your browser is your light or dark theme preference, in local storage, and only if you press the button.
Like any site, the hosting provider may log the requests it receives — IP address, date, page requested and user agent — in order to operate the service and protect it from abuse. That log is handled by the provider under its own policies; the author does not use it to profile visitors.
If a future version of the extension changed how it handles information, this policy is updated before that version ships, and the effective date in the header reflects it. A material change — for instance any transfer of data off your machine, which does not exist today — would also be announced in the release notes.
Write to jesusandrescorreal@gmail.com to exercise any right over your data, report a privacy problem, or ask anything about this document. Since the extension sends no information anywhere, the author holds no data of yours to correct or erase: whatever exists is on your machine and under your control.
This policy is governed by Colombian law, in particular Law 1581 of 2012 and its implementing regulations on the protection of personal data.