Privacy claims are common in online image tools, but the wording alone does not show what happens to a selected file. This article describes visdraw’s current architecture, states what the service does and does not handle, and shows you how to inspect the image-processing path yourself.
A privacy promise is something you have to trust. A privacy architecture is something you can check. We would rather be checked.
The question that actually matters
When you open a photo in a web tool, one of the first questions is: are the image bytes sent to a server? If they are, retention rules, encryption, deletion timelines, and staff access controls all become relevant. If the editor does not send the image for processing, that path does not create a server-side image copy — although ordinary account and website data still needs its own privacy rules.
Many web editors answer that question with "yes, but we delete it afterward." That is a policy commitment: it depends on the upload, storage, access, and deletion systems all behaving as described. Local processing removes that particular storage path instead of asking you to trust a retention promise.
How the architecture works
The editor uses standard browser capabilities. File selection grants access to the image you chose, WebGL and Canvas perform the editing work, and browser encoders create the exported file.
The file is read, not uploaded
Selecting an image hands the page a reference to that file, which the editor decodes into memory in the tab. Reading and transmitting are separate operations; the current editing flow reads the selected image without submitting it to a rendering server.
Pixels are processed in the browser
visdraw uses WebGL, Canvas, and local JavaScript processing, drawing on the device’s CPU or GPU as each operation requires. Slider previews do not wait for a server-rendering round trip.
Export is encoded locally
Converting the rendered image to PNG, JPG, WebP, or PDF happens in the browser. The browser then offers the finished file for download; a remote image service does not assemble it.
Images are session-based
There is no visdraw cloud library holding your originals or rendered edits. After a refresh or closed tab, the current image session cannot be recovered from the visdraw service. Preferences and personal filter presets are separate and may remain in local browser storage.
Browser file permissions limit the page to files you explicitly select or otherwise grant to it, such as a main image or watermark asset. The page cannot independently enumerate your folders or scan your drive. Browser extensions and a compromised device sit outside that boundary.
Verify the image path in the Network panel
This is the part we would encourage you to actually do — not only here, but with any tool you hand a sensitive image to.
- 1
Open your browser developer tools
Use your browser’s menu or keyboard shortcut to open developer tools, then switch to the Network tab. It lists the requests the page makes while the panel is open.
- 2
Clear the log, then load an image
Press the clear button so you start from an empty list, then open a photo in the editor. Watch what appears. Loading a local file should produce no upload request carrying your image.
- 3
Do a real edit while watching
Adjust exposure, apply a mosaic, and run a filter. Inspect outbound request methods, content types, sizes, and details. Normal page requests may still appear; the relevant question is whether any request contains your selected image bytes or a rendered copy.
- 4
Export the result, still watching
Export a PNG or WebP. The file appears in your downloads without a corresponding upload, because the encoding happened in the tab.
- 5
Use offline mode as a second check
After the editor, its assets, and an image have loaded, select Offline in developer tools and try a few current editing and export actions. Continued operation can support the conclusion that those actions do not need live server rendering, but it does not prove that no earlier upload occurred. Reloading, signing in, or fetching an unloaded resource may still require a connection.
What the website and account system may handle
“Images are not uploaded for editing” does not mean the website performs no data processing. visdraw still has hosting, cookie preferences, and an optional account system. The important distinction is between the images and rendered edits, which are not submitted as editing input, and ordinary website, browser-storage, and authentication data, which is handled for its stated purpose.
| Category | Status | Notes |
|---|---|---|
| Your images and edits | Not sent for processing by the editor | Decoded, processed, and exported inside the browser tab |
| Image metadata (EXIF, location) | Not sent with the editing flow | The original file is not uploaded for processing, so its metadata is not included in an editing request |
| Account details | Handled if you register or sign in | Supabase handles email, authentication credentials, and session data. Google also handles data if you choose Google sign-in. Editing does not require an account. |
| Routine website requests | Processed to deliver the site | Hosting and authentication infrastructure may receive IP addresses, request paths, headers, and session information. visdraw does not currently load analytics, advertising, or payment SDKs. Details are in the privacy policy. |
| Cookies and similar storage | Required or choice-based | Authentication may use required session storage, while optional choices and editor preferences are kept in your browser. Details are on the cookie page. |
This has practical limitations. The visdraw service cannot show a cloud gallery of past images, recover an unexported image session after a refresh or closed tab, or inspect an image unless you deliberately send it. Personal filter presets may remain in the current browser, but they do not contain the original image, text, brush work, liquify edits, color-replacement rules, or watermark content.
What the editor does not send to us
- The pixel contents of images you open. Faces, documents, dashboards, and unreleased designs are processed in the browser instead of being submitted as editing input.
- A server-side history of the rendered result. Crops, redactions, color work, text, and watermarks do not create a corresponding image history on the visdraw service.
- EXIF and location data from the original file. Because the original is not uploaded for processing, its camera and location metadata is not sent with an editing request.
- Files you did not select. Browser permissions provide references to files you explicitly choose; the page cannot independently enumerate other local files.
- The unexported canvas after a refresh or closed tab. There is no cloud image copy for the service to restore, and locally stored filter presets are not image backups.
This narrows what a server breach, internal access mistake, or legal request could expose from the visdraw image-editing path: a server cannot disclose an image copy it did not receive. That conclusion does not cover your device, browser extensions, synced folders, or the final recipient.
Where our responsibility ends
On-device processing avoids creating an image-in-transit or stored image copy on the visdraw service as part of the editing flow. It does not make your device or the rest of the sharing process secure.
If an image is genuinely sensitive, treat the editor as one link in a chain: use a browser profile and device you control, redact carefully, and consider where the export will be stored or shared. Local processing narrows the editor’s server-side exposure; it cannot secure the rest of that chain.
Frequently asked questions
Are my photos uploaded to visdraw’s servers?
No. Images are decoded and processed inside your browser tab using WebGL, Canvas, and local JavaScript, and exports are encoded there as well. You can inspect the Network tab in developer tools to confirm that the editor does not send the selected image for processing.
How can I check that a photo editor is not uploading my files?
Open developer tools, clear the Network tab, then load, edit, and export an image while inspecting outbound requests. Continued editing in offline mode is useful supporting evidence, but the request log is the more direct check.
Do you store my edited images or keep a history?
The visdraw service has no cloud image library or server-side image history. Closing or refreshing the tab ends the current image session, which the service cannot restore, so export before you close. Personal filter presets may remain in this browser, but they do not contain image pixels.
Does the visdraw service receive EXIF or location data from my photos?
Not through the image-editing flow. The original file is not uploaded for processing, so its EXIF and location data is not sent with an editing request. The current Canvas-based export does not copy the original EXIF, but verify the exported file when metadata removal matters.
Do I need an account to edit?
No. Editing works without registering. If you create an account, Supabase handles email, authentication credentials, and session data. Google also handles data if you choose Google sign-in, as described in the privacy policy.
Is it safe to edit ID documents, contracts or medical images here?
Not submitting the selected file for processing reduces server-side transfer and storage exposure, but it does not remove every risk. Assess the device, browser extensions, screen-recording or sync software, organizational requirements, and where the exported file will be shared.
Does the editor work offline?
After the page assets and image have loaded, core editing and export actions in the current session can usually continue without a connection. Reloading the page, signing in, or fetching resources that were not already loaded can still require network access.
Written by
The visdraw team
Product & engineering