Images & photos · Browser Image & Drawing Editor
How to verify an image editor never uploads your photo: network panel
· Why it matters
image-editing canvas browser-processing
'Nothing is uploaded' is a claim anyone can make; the browser's developer tools let you test it in a minute. This post shows how to watch the network panel while editing and how to read what you see.
A promise you can test — why 'processed locally' should be verified rather than believed, and how the browser makes that possible
A privacy claim becomes useful when a reader can challenge it. 'Processed locally' should be verified as a bounded technical statement, not accepted as a slogan. The practical test is simple: load the page, clear the Network panel after initial assets arrive, open a harmless distinctive image, and observe what requests appear during editing and export.
Static evidence gives that runtime check a second foundation. The editor's source has no network API calls, and automated tests prohibit fetch, XHR, sockets, beacon, and remote origins. Those findings support the claim about the editor path, while the browser session tests the deployed page you actually used.
Opening the network panel — where to find it in Chrome, Firefox, Edge and Safari and what an empty log means
Open the browser’s developer tools and select the Network panel; exact menu labels vary by browser version, but the workflow is the same in Chrome, Firefox, Edge, and Safari. Let the page finish loading first, then clear the captured entries. An empty log is not the goal, because the page may legitimately request its own assets or send disclosed consent-gated analytics.
After clearing, select the test image and perform a crop, annotation, and export. Search new request details for the distinctive filename, bytes, or marker content. A large POST or PUT deserves inspection, yet its method and size alone cannot prove that it carries the selected photo. Read the body or payload evidence before drawing a conclusion.
Open a browser network panel and interpret requests; exact menus vary by browser version
Page loading and image editing are different phases of the observation. Before opening a file, the browser may fetch scripts, styles, fonts, images, or other assets needed to render the tool. Consent-gated analytics may also appear according to the product configuration. Those requests establish page traffic, not an upload of the selected image.
Clear the panel only after that setup phase, then open a distinctive harmless file and edit it. Compare the post-clear request list with the file’s name and known marker content. The narrower question is whether any later request carries the selected photo; requiring every request to vanish would confuse ordinary page operation with image transfer.
What an upload would look like — POST or PUT requests with a large payload, and why their absence is meaningful
An upload would normally leave a request carrying image data, whether through a multipart body, a binary payload, or an encoded field. A POST or PUT with a large body is therefore a useful lead, but it is not conclusive on its own: method and size cannot identify the body’s contents without inspection. Search for the distinctive test marker and examine payload details when a request looks relevant.
The editor's own source has no network API calls, and automated tests prohibit fetch, XHR, sockets, beacon, and remote origins. That static boundary explains why a post-clear runtime session should not reveal an image transfer. Asset and consent traffic may remain visible; the meaningful absence is a request that carries the selected photo.
Worked example: cropping and annotating a photo with the panel open — walking through a session where no request carries the image
Use a harmless image with an unmistakable marker, such as a short filename and a coloured test patch. Let the page load, clear the Network panel, open the file, crop it, add a line or rectangle, and export the result. Keep the panel visible during each operation so the observation covers the actual sequence rather than only the initial file picker.
Review new requests for the marker, filename, or a payload that could contain the image. Page assets and consent-gated analytics may still appear, and that is compatible with local image processing when their data excludes file contents and names. The useful result is not a theatrically silent panel; it is no request carrying the selected photo.
Beyond the panel — Content Security Policy, the absence of third-party scripts, and why a strict policy is a stronger guarantee than a privacy page
A Network-panel observation is stronger when it is read alongside the application’s source and policy boundaries. Content Security Policy, script inventory, and the absence of third-party code can narrow possible routes, but a privacy page alone is not a technical control. Here, editor source and automated tests provide concrete evidence that the editing code does not call network APIs.
Do not turn that evidence into a demand for a perfectly quiet browser. The page may load assets, and consent-gated analytics may operate under its disclosed rules. The relevant check remains whether any request made after file selection carries the image bytes, its distinctive marker, or its filename as upload data.
Source tests and request inspection strengthen the claim; production analytics remains a separate disclosed path
This check covers the page and browser requests you can observe; it does not audit browser extensions, operating-system sync, managed-device software, clipboard history, or the destination where you later send the export. A local editor can avoid its own image upload while another installed service copies or indexes the resulting file. Those are separate trust boundaries.
It also does not prove that every future deployment behaves identically. Repeat the narrow runtime check when the environment, release, or policy matters. Distinguish page and analytics traffic from an image payload, inspect suspicious request bodies, and treat the file’s later attachment or storage as a new disclosure event.
Takeaway: trust, then verify, then relax — how the Browser Image & Drawing Editor is built to pass this test and how to run it yourself
Trust is more useful after verification. The Browser Image & Drawing Editor’s source and privacy tests provide a local-processing boundary, while a post-load Network-panel check lets you challenge the deployed behaviour with a harmless distinctive file. Clear after page assets arrive, edit and export, then inspect any request that could carry the marker or bytes.
The conclusion should stay precise: ordinary page and disclosed analytics traffic can exist without being an image upload. What matters is whether a request carries the selected photo. If the runtime observation, source evidence, and tests agree, you have a defensible result for that editor session, not an unsupported promise that every browser surface is silent.