Why Your Profile Picture Stays Private With DPSizer
Browser-based processing explained: why structural architecture provides a stronger privacy guarantee than policy promises alone.
Every time you use an online image tool, something happens to your photo. On most tools, that something is an upload — your photo leaves your device, travels across the internet to a remote server, gets processed there, and comes back. The tool worked. The result downloaded. But your photo visited a server you do not control, operated by a company whose data practices are governed entirely by a privacy policy you probably did not read.
DPSizer works differently. Not because of a privacy policy — because of its architecture. Your photo never leaves your device. Not as a matter of policy. As a matter of how the tool is built.
This page explains what browser-based processing means, why architecture matters more than policy when it comes to image privacy, and how you can verify DPSizer's local processing claim yourself without taking anyone's word for it.
The Question Every Image Tool Should Answer
When you select a photo in an online tool and click a button, where does your photo go?
It is a simple question. Most online image tools do not answer it clearly — not because the answer is complicated, but because the honest answer for most tools is: it goes to our server. That is not necessarily malicious. Server-based processing is a legitimate architectural choice and the dominant approach for online tools. But it means your photo left your device, and what happens to it from that point is outside your control.
The question matters more for photos than for most other types of data. A profile picture is typically a photograph of a person's face — your face, or the face of someone you know. It is personal in the most literal sense. It is identifiable. Under data protection frameworks including GDPR, a photograph of a person's face is explicitly classified as personal data.
When you use a tool to resize that photo, you deserve a clear answer to where it goes. DPSizer's answer is: nowhere. It stays on your device. Here is exactly why that is true, and how to confirm it yourself.
What "Browser-Based" Actually Means
Browser-based processing is not a marketing description. It is an architectural fact about where computation happens. Understanding what it means requires understanding three things: what the Canvas API is, what local processing means for your photo specifically, and how to verify the claim independently.
The Canvas API — your browser's built-in image processor
The Canvas API is a standard feature built into every modern web browser — Chrome, Safari, Firefox, Edge, and all their mobile equivalents. It provides a programmable drawing surface that web pages can use to create, manipulate, and export images entirely within the browser environment, without sending data to a server.
The Canvas API is not a plugin, an extension, or a third-party library. It is part of the HTML standard — a core browser capability that has existed in all major browsers since around 2008 and is now universally implemented. When a web page uses the Canvas API to process an image, that processing happens inside the browser, on the device running the browser, using that device's processor and memory.
DPSizer uses the Canvas API for every image operation: decoding the file you select, rendering it on a square canvas, applying fit mode and background transformations, generating the circular preview overlay, and exporting the finished result. None of these operations require a network connection or a remote server. The Canvas API provides all of them natively, locally, within the browser.
What "local processing" means for your photo
When you select a photo in DPSizer, the browser reads the file from your device's storage into browser memory. This is a local file read — the same operation that happens when you open a file in any application on your device. No network request occurs at this step.
The browser decodes the image file into raw pixel data and passes it to the Canvas API. DPSizer's code draws this pixel data onto a canvas element, applies your chosen transformations, and renders the result. Every adjustment you make — dragging the image, changing the background, toggling the circular preview — triggers a canvas redraw using the pixel data already held in browser memory.
When you click Download DP, the Canvas API converts the canvas contents to your chosen format and quality level, and the browser writes the resulting file directly to your device's downloads folder. This is a local file write — again, no network request.
At every step, your photo exists in browser memory on your device. It does not travel across a network connection. It does not reach a server. It does not leave the device in any form.
The offline test — how to verify DPSizer processes locally
You do not have to take DPSizer's word for local processing. You can verify it in under thirty seconds.
Open DPSizer in your browser and wait for the page to fully load. Then disconnect from the internet — turn off Wi-Fi, enable airplane mode, or unplug your network cable. With no internet connection active, upload a photo, make adjustments, and click Download DP.
If DPSizer required a server to process your photo, this would fail — the tool would be unable to send your photo to the server or receive the processed result back. Instead, the tool works identically to when you are connected. Every feature functions. The download completes. The processed DP appears in your downloads folder.
This is not a trick or a workaround. It is the expected behaviour of a tool built on local processing. The offline test is the most direct proof that no network connection — and therefore no server upload — is involved in DPSizer's image processing. Try it whenever you want to confirm the claim independently.
What Happens on Server-Based Tools
Understanding why browser-based processing matters for privacy requires understanding what the alternative looks like in practice. Server-based image processing is not inherently malicious — but it has structural privacy implications that are worth understanding clearly.
The upload step most tools don't explain clearly
When you use a server-based image tool, your photo is transmitted from your device to a remote server as part of the processing workflow. This upload step is often invisible in the user interface — you select a file, the tool appears to process it, the result downloads. No explicit "your photo is being uploaded" notification appears. The upload happens as an implementation detail that the tool does not surface to the user.
On a fast internet connection, the upload completes quickly and the experience feels instantaneous. On a slow connection, the delay is visible — the tool takes longer to "process" the image than the actual resizing operation would require, because most of that time is upload and download latency rather than processing time. This latency is the clearest user-facing indication that a server is involved.
Once uploaded, your photo exists on a remote server. It has been transmitted over your internet connection — potentially over multiple network hops through infrastructure you have no visibility into — and now resides in the memory or storage of a computer operated by the tool provider or their hosting partner.
What a server can do with an uploaded image
The server that receives your photo has technical access to it. What the operator of that server chooses to do with that access is governed by their privacy policy and data retention practices. The range of what is technically possible includes:
- Storage — the photo may be written to disk as part of the processing pipeline and retained for a period after the download completes. Retention periods vary by tool and are specified (or not specified) in privacy policies.
- Logging — server logs routinely capture metadata about requests, including IP addresses, timestamps, file sizes, and in some implementations, file names. A log entry associated with a profile picture upload may be retained long after the image itself is deleted.
- Third-party exposure — most server infrastructure involves multiple parties. Hosting providers, CDN providers, load balancers, monitoring services, and analytics platforms all have some level of access to the data their systems carry. A photo uploaded to a tool's server may pass through several third-party systems before the processed result returns to your browser.
- Legal process — a server operator can be compelled by legal authority to produce data held on their servers. A photo uploaded to a tool's server is, from the moment of upload, potentially subject to legal process directed at that operator.
- Security incidents — servers are targets for security breaches. A data breach affecting a tool provider's infrastructure could expose uploaded images. The risk of a breach affecting any individual provider is low but not zero.
None of these outcomes are inevitable or even likely for any specific tool. The point is that all of them are structurally possible once a photo reaches a server — and none of them are possible for a photo that never leaves the device.
Why privacy policies aren't enough
A privacy policy is a statement of intent. It describes what the operator commits to doing and not doing with data they receive. A good privacy policy from a reputable operator is meaningful — it creates legal accountability and reflects genuine organisational commitment to responsible data handling.
But a privacy policy does not change the architecture. A server-based tool with an excellent privacy policy still uploads your photo to a server. The photo still exists on remote infrastructure. The upload still happened, and the structural possibilities that come with server-side storage — breach exposure, legal process, third-party infrastructure access — are still present regardless of how clear and honest the policy is.
Architecture determines what is possible. Policy determines what is intended. For personal photos, the safest position is one where the structural possibilities themselves are eliminated — not one where they are present but managed by policy. A photo that never reaches a server cannot be exposed by a server breach. That is not a policy guarantee. It is a physical fact.
What DPSizer Does and Does Not Store
Transparency about data practices should be specific, not general. Here is a precise accounting of what DPSizer stores, transmits, and collects — and what it does not.
Your images — never stored, never transmitted
DPSizer does not store your images. It does not transmit them. They do not reach DPSizer's servers at any point during or after a session.
When you select a photo, it is loaded into browser memory on your device. When you close the DPSizer tab, refresh the page, or click Start Over, that browser memory is cleared. The photo ceases to exist in any form accessible to DPSizer — not because it was deleted from a server, but because it never reached one. There is no server-side copy to delete.
This is a structural guarantee, not a retention policy. DPSizer cannot produce your photo in response to a data subject access request, a legal subpoena, or any other request, because DPSizer does not have your photo. It was never transmitted to any system DPSizer operates.
Usage analytics — what may be collected and what is not
DPSizer may collect anonymous product usage data. If analytics are enabled, this may include events such as which tool features were used, which export format was selected, which fit mode was chosen, and general session information such as browser type and device category. This data is used to understand how the tool is being used and to prioritise improvements.
What this data never includes: your image content, your image filename, any information derived from the content of your photo, or any personally identifiable information linked to your tool usage. The analytics, if active, record that someone used Full Photo mode and exported a 640px JPG — not who that person is or what their photo contained.
The current status of DPSizer's analytics implementation and the specific analytics provider used, if any, is documented in the Privacy Policy. If you prefer to block all analytics entirely, a browser extension such as uBlock Origin will prevent any analytics scripts from loading without affecting the image processing functionality, which is independent of any analytics implementation.
No accounts, no filenames, no image content — ever
Three things DPSizer will never collect under any circumstances:
- No accounts — DPSizer does not require, offer, or create user accounts. There is no login, no registration, no user identifier linked to your tool usage.
- No filenames — the name of the file you upload is not transmitted to DPSizer's servers and is not included in any analytics data. Your filename stays on your device.
- No image content — the pixel data, visual content, or any derivative of your image is never transmitted, stored, analysed, or used by DPSizer in any form. The image exists in your browser's memory. It stays there.
GDPR and Image Privacy — What It Means for Profile Picture Tools
The General Data Protection Regulation (GDPR) applies to the processing of personal data of individuals in the European Union. A photograph of a person's face is personal data under GDPR — specifically, it is data that can be used to identify a natural person directly. In some contexts, facial photographs may also qualify as biometric data, which carries additional protections under GDPR Article 9.
For users in the UK, the UK GDPR — which mirrors the EU regulation with minor modifications following Brexit — applies the same protections.
When a server-based image tool receives a photograph of a person's face uploaded by a user in the EU or UK, that tool is processing personal data within the meaning of GDPR. The tool operator becomes a data controller or data processor with obligations under the regulation: to have a lawful basis for processing, to retain data no longer than necessary, to provide data subject rights including access and erasure, and to implement appropriate technical and organisational security measures.
DPSizer's browser-based architecture sidesteps this question at the structural level. When a photo never reaches DPSizer's servers, DPSizer never processes personal data within the meaning of GDPR. There is no data controller obligation to fulfil, no retention period to specify, and no data subject rights to implement in relation to image content — because no image content ever enters DPSizer's systems. The personal data stays on the user's device throughout. The user remains the sole controller of their own image data.
Frequently Asked Questions
Can DPSizer see my photos?
No — and not just as a matter of policy. DPSizer's servers never receive your photos, which means no DPSizer employee, system, or process can access them. Seeing your photo would require it to be transmitted to a server DPSizer controls. That transmission never occurs. DPSizer uses the Canvas API to process images locally in your browser, which means your photo exists only in your browser's memory on your device.
What happens to my photo when I close DPSizer?
When you close the DPSizer browser tab, refresh the page, or click Start Over, the browser memory holding your photo is cleared. The photo ceases to exist in any DPSizer-accessible form at that point. Because your photo never reached DPSizer's servers, there is no server-side copy to persist after your session ends.
Is DPSizer safe to use for photos of my children?
Yes. Photos of children are among the most sensitive personal images anyone handles, and the privacy implications of uploading them to a server-based tool are significant. DPSizer's local processing architecture means photos of children never leave your device — they are not uploaded to DPSizer's servers, not stored remotely, and not accessible to anyone other than you.
Does DPSizer work without an internet connection?
Yes, after the initial page load. Once the DPSizer page and its assets have loaded in your browser, all image processing functionality works without an internet connection. Upload a photo, make adjustments, preview the circular crop, and download the result — all of this works offline because none of it requires a network request.
Who can access my photos if I use DPSizer?
Only you. Your photo exists in browser memory on your device during a DPSizer session and nowhere else. No DPSizer employee can access it — it never reaches DPSizer's servers. No third-party infrastructure provider can access it — it never passes through any third-party network in image form. The only person with access to your photo during a DPSizer session is you, on your device, in your browser.
Architecture Is the Privacy Guarantee
There are two ways for an online tool to protect your privacy. The first is to receive your data and commit, through policy, to handling it responsibly. The second is to be built in a way that never receives your data in the first place.
DPSizer is the second kind of tool. Not because of a commitment made in a privacy policy — because of a technical decision made in how the tool was built. The Canvas API processes images locally. Local processing means no upload. No upload means no server receives your photo. No server receiving your photo means no server can misuse it, lose it in a breach, or produce it in response to legal process.
Policy describes intent. Architecture determines what is possible. For a personal photo — a photo of your face, your family, your children — the safest tool is one where the structural possibilities themselves are eliminated, not one where they are present but managed by policy.
That is what browser-based processing means. That is why it matters. And that is what DPSizer is built on.
For the full technical explanation of how the Canvas API processes your image from selection to download, see our How a Profile Picture Resizer Works — And Why Browser-Based Matters guide. To use the tool, see our WhatsApp DP Resizer — Full Tool Guide covering every step from upload to export.