Privacy Policy

Last updated: 7 October 2026

1. Who we are

MiniPx (minipx.com) is operated by Gaurav Bhowmick, an individual sole proprietor based in India. For any privacy question, write to contact@minipx.com.

2. Your image files

This is the most important thing in the document. Your image files never leave your browser. When you drop an image into MiniPx, it is read, processed, and re-encoded entirely by JavaScript running on your device. The compressed output appears in your browser memory and is downloaded directly to your computer. At no point is the image data transmitted to our servers, to Netlify, to Google, to Paddle, or to anyone else.

You can verify this yourself: open browser DevTools, switch to the Network tab, drop in an image, watch the compression run. No image data is transmitted. The compression engine runs in your browser, so its code is delivered to your device and available for inspection there.

Three honest footnotes, because "never leaves your browser" should survive scrutiny rather than depend on you not looking. First, the AI-powered tools download a model file from a third party the first time you use them — that is a download to your device, never an upload of your image. Section 7 covers it. Second, the page analyzer at /analyzer/ is the one tool on this site that talks to our server: you give it a public website address, and our server fetches that page's HTML and the response headers of the images it references so we can estimate savings. It never downloads image bytes, and it has nothing to do with the files you compress. Neither footnote touches the images you process.

Third, and this is the real one: if you are a Pro subscriber you can switch on Cloud HD — or use one of the four Cloud HD photo-repair tools — and when you do, that photo is uploaded to our server for that run. Cloud HD is the only part of MiniPx that ever does this, it is off until you turn it on, and you agreed to it — including the 14-day cancellation waiver for runs — when you bought Pro; the tools tell you before every run that the photo goes to our server and when it is deleted, and nothing is asked of you again. Section 2A sets out exactly what happens to the file, who sees it and how long it exists. If you never switch it on and never use those four tools, the sentence at the top of this section is unqualified: your images never leave your browser.

The same promise covers the MiniPx Chrome extension, which processes your images entirely on your own machine; its only network request is fetching an image you right-click and hand to it. Because an extension asks for browser permissions this site cannot, it has its own policy setting out each one: see the Chrome extension privacy policy.

2A. Cloud HD: the one time an image leaves your browser

Cloud HD is how a Pro account runs a bigger, better model than your device can manage, on a server we rent, and it is available only on a paid Pro account. On three tools — the background remover, the image upscaler and the passport photo maker — it is an option: they run on your device unless you switch Cloud HD on, per tool. Four more tools — restoring, colourising and enhancing old photos, and removing an object from one — are built on the same server and the same meter, and have no on-device mode. None of the seven asks you to confirm anything before a run: the cancellation waiver that covers Cloud HD runs is part of what you agreed to at checkout (section 9), and each tool states, in plain text beside its run control, that the photo goes to our server and when it is deleted. If you never switch Cloud HD on and never use those four tools, nothing in this section ever happens to you.

What is sent. One photo, the one you are working on, at the moment you press the button. Nothing else: not your other files, not your filename, not where the photo was taken, not what camera took it. Before the model sees your photo at all, our server re-encodes it into a plain image — pixels, the right way up, in a standard colour space — and throws the original file away. That step exists to defend the server against malicious image files, and it has the side effect of stripping the location and camera information your phone writes into a photo. For the object remover, the mask you paint travels with the photo and is deleted with it.

Where it goes. The upload goes to Cloudflare R2, object storage operated by Cloudflare, Inc. The model runs at Modal Labs, Inc. Both are in the United States, so your photo is processed in the United States. Section 12 covers what that means legally.

How long it exists. We delete your photo as soon as the run finishes, and in every case within 24 hours. Specifically: the file you uploaded is deleted before we even hand you the link to your result; the result itself is reachable for five minutes through a short-lived link and then expires; a sweeper runs every fifteen minutes over anything left behind; and a rule on the storage bucket deletes anything at all that survives a day. That is our promise and our machinery, not a policy of the companies above. For passport and ID photos we go further: both the photo you sent and the photo we made are deleted as soon as your browser confirms the download, rather than waiting out the five minutes.

What it is never used for. Your photo is used to produce your result and for nothing else. We do not use it to train, tune, evaluate or improve any model, and our contract with the company that runs the model for us does not permit them to use it for that either. Nobody here looks at it — there is no screen anywhere in MiniPx that could show it to us, and by the time you could ask, it is gone.

What we keep afterwards. A record of the run, with no image in it: which tool, which model and which version of it, whether it worked, how big the file was going in and coming out, how long it took, and when. Section 5 lists the fields. You can see this list yourself on your account page, which is also where we show you which model processed your photo.

What it costs you. Each run uses one unit of your monthly cloud allowance, and the meter is shown before every run. A few high-cost runs — the tools mark them as HD runs — also draw a separate monthly HD counter, shown the same way before the run. A run that fails on our side is not charged.

If you would rather not. Leave the switch off. The background remover, the upscaler and the passport photo maker still work on your own device exactly as they did before; the four photo-repair tools are server-only, so not using them is the whole choice; and everything else on MiniPx — compression, conversion, resizing, the PDF tools, the favicon generator — never had a server option in the first place and still does not.

3. What we do collect: anonymous analytics

We use Google Analytics 4 (property ID G-CPKR150KT7) to understand traffic patterns and feature usage. The data sent to Google is anonymous and aggregated. It includes:

• Page views, scroll depth, and time on page (bucketed: 10s / 30s / 60s / 3min / 10min).
• Approximate location at country and city level (derived from IP, which Google anonymizes before logging).
• Coarse device class (mobile / tablet / desktop), viewport size, network connection class (4G / wifi when the browser exposes it), and your top language preference.
• Traffic source attribution: the referring website’s hostname only (never the full URL or query string), plus any UTM campaign parameters present in the link you clicked.
• First-touch attribution: the first time we ever saw your device, we record the original referrer and UTM in your browser’s localStorage. We send this back with later events so we can answer questions like "where did this user originally come from?" without re-identifying you.
• A random per-tab session ID (regenerated whenever you open a new tab) so events from the same browsing session can be grouped. Not linked to any identity.
• Outbound link clicks: domain only (e.g. "github.com"), never the full destination URL.
• Compression-related event metadata: file extension, input and output sizes in KB, compression ratio, format chosen, mode used. We do not send filenames or file contents.
• Interactive tool events: slider changes, toggle changes, preset selections, Pro upgrade prompts, errors classified into safe categories. None include file content or personal data.
• Pro feature interaction (visible to us only as anonymous counts): which Pro features are explored (panel expanded), which controls are touched (watermark anchor, opacity, scale, codec settings, responsive sizes, multi-format selections, saved presets, platform presets, rename templates), which Pro tier prompts you see, and which upgrade nudges convert to a /pricing/ visit.
• Pro funnel telemetry: pricing-page views, plan-card impressions, plan-CTA clicks, Paddle checkout open/close/complete/error (no card data ever seen by us — Paddle handles that), activation success/error, and a composite "Pro engagement score" (0–10) per session summarising how deep into the upgrade funnel a session reached.
• Account-page churn signals (Pro users only): manage-subscription / upgrade-to-annual / device-removal clicks. We use these to measure where Pro users get stuck or churn. We never see your billing email, card, or any Paddle PII through these events.

We use this data to understand which tools are popular, which need work, where users get stuck, and which traffic sources convert. We never tie this data to a person or attempt to re-identify visitors. Google’s own privacy policy and your control over Google’s tracking apply: see policies.google.com/privacy and Google’s opt-out browser add-on.

If you decline analytics, nothing is sent. Once you have declined — on our own consent banner, which asks in the EEA, the UK and Switzerland (between 8 September and 4 October 2026 Google's consent message asked there instead) — your browser sends Google Analytics nothing at all: no page views, no events, and not the cookieless signal Google's Consent Mode would otherwise still send. That holds from the moment you decline, on every page after it, for as long as your browser keeps the choice (section 6). The analytics script file may still be fetched as part of the page, but it is switched off and transmits nothing. Before you have answered, and after you accept, analytics works as described above.

4. What we do collect: payments (Pro only)

If you purchase MiniPx Pro, the payment is processed by Paddle.com Market Ltd. Paddle is the merchant of record. They collect what is necessary to complete the transaction and handle tax compliance:

• Your name and billing email.
• Your billing country (for VAT, GST, or sales tax).
• Card details (which Paddle never shares with us).
• Your purchase amount and the product purchased.

Paddle stores this data under their own privacy policy: paddle.com/legal/privacy. From Paddle we receive only a webhook notification that the purchase occurred, with your customer ID hashed before we log it. We do not store your name, email, or card information on our servers.

Paddle Retain runs on the pricing page. Paddle’s checkout script loads a second script from public.profitwell.com (Paddle Retain, formerly ProfitWell) whenever you open /pricing/ or one of its translated versions (/de/pricing/, /fr/pricing/, /es/pricing/, /pt/pricing/, /hi/pricing/, /id/pricing/). It is Paddle’s subscription-analytics and failed-payment-recovery tool. It sends data about the page to retain-api.profitwell.com and api.profitwell-events.com, and it can display a payment-recovery message in a frame served from Paddle’s own domain. We do not control what it collects and we receive none of it directly — it reports to our Paddle account.

Two things worth saying plainly about it. It is a third-party script, so it is the one part of this site that is not covered by the analytics question in the cookie banner — that banner governs Google Analytics, not this. And it runs only on the pricing page: it is not present on the homepage, on any of the tools, or on the account and activation pages. It never sees your images: the free tools never send an image anywhere, and a Cloud HD run (§2A) goes to our own server, never to Paddle. If you would rather it did not run at all, a content blocker will stop it without affecting anything else on the site.

Your Pro license itself (the Paddle transaction or subscription ID) is stored in your browser's localStorage on the device where you activated it. You can clear it at any time from the account page.

5. What we store on our own servers (Pro licensing)

We do run server-side storage. It exists to make Pro accounts work — to sign you in, to know what you have paid for, and to stop one purchase being shared across a hundred devices. Since August 2026 it is a Postgres database hosted by Supabase in the United States (us-east-1), and it holds these record sets:

• Your account: the email address you bought with (Paddle passes it to us when a purchase completes, and it is what you sign in with), a random account ID, and the times you created the account and last signed in. Earlier versions of this policy said we did not hold your email at all; that stopped being true when accounts replaced licence keys in August 2026, and this section was corrected on 27 August 2026.
• The link between your Paddle customer record and your account: your Paddle customer ID, your account ID, and the email address Paddle gave us with the purchase. That email is a second copy of the one above — we hold it in two places, not one — and this is the row support looks you up in when you write to us about a purchase. In our server logs the Paddle customer ID is hashed before it is written, never logged in full.
• Your entitlement: plan (monthly / annual), status, the period end, a scheduled cancellation date if you have asked for one, and the Paddle subscription and transaction IDs. Written only by Paddle's webhook and by a nightly check against Paddle — never by anything in your browser.
• Devices: the random identifier your own browser generated (see "minipx_device_fp" below), never a hardware serial or anything issued by your operating system, with first-seen and last-seen times. This is what the 5-device limit counts.
• Sign-in sessions: for each browser you are signed in on, when the session started, when it was last used, the full user-agent string your browser sends, and the IP address the request came from. Both of those last two are stored as received — the sign-in service records them, not us — and they are only ever coarsened on the way out: the account page shows you a browser and operating-system name ("Chrome on macOS") and your IP address with the last part removed, never the raw values. You can see and end these sessions from the account page. A session stops working after 7 days without use, and after 30 days whatever you do.
• Revocations — if a purchase is refunded or charged back, the entitlement is marked revoked with the time, the reason and the Paddle event that triggered it, so access stops immediately rather than on the next Paddle round trip.
• Consent records, keyed to your account — one row each time you agree to something that changes what you pay, which today means an in-place plan change: a version identifier for the confirmation wording you were shown, a SHA-256 hash of that exact wording, your browser's timestamp, which plan you moved from and to, the subscription it applied to, and whether the change went through. Not the wording as free text — the hash proves what you were shown. The equivalent record for the original checkout is still written to the older Netlify Blobs store described at the end of this section, where it is keyed to the Paddle transaction ID and carries your Paddle customer ID.
• Rate-limit counters used to stop abuse of the sign-in and account endpoints. They are keyed to a SHA-256 hash of your IP address or email address, never the value itself, and they live in short time buckets.
• Paddle webhook event IDs, held briefly so a retried delivery is not processed twice. No customer data in them.
• Tool usage counts (Pro accounts only): which tool page you downloaded output from — "compress-image", "image-upscaler" and so on — how many times, and the first and last time. That is the whole record: no file names, no sizes, no dimensions, and never the image itself, which still never leaves your browser. It exists for one reason, to decide refund requests under the "Using Pro after you buy" rule on the Refund Policy, and it is read by a person only when you ask for a refund.
• Anonymous daily usage counts, not linked to any account: one row per day for each combination of tool, what happened (a run started, finished, failed, was refused, a file was downloaded, or you voted on a result), the input and output formats, a reason code from a fixed list when something failed, coarse bands for file size and saving, a band for the image's pixel count, which browser engine was used, whether the run was on a Pro account, and one further detail drawn from a fixed list — which is, depending on the tool, the upscale factor, a band for how many pages or how many files were in the batch, a band for OCR confidence, which compression mode you chose, whether an AI run was the instant or the standard model and whether it ran on your device or in the cloud, or which way you voted — plus a count of how many times that combination happened. There is no account ID, no session, no IP address, no file name, no file size and no image in it, and every text value has to come from a closed list the server refuses to write outside of. It answers questions like "how often did AVIF compression fail on Firefox yesterday"; it cannot answer who. Two things on the row relate to your account rather than your file: the Pro flag, which is a yes or no and never an identifier, and the instant/standard/cloud/device detail above, which only Pro runs can produce. Before 23 September 2026 the Pro flag was recorded incorrectly and every row read "not Pro"; it is described here as it now behaves.
• Cloud HD runs (Pro accounts only, and only if you switch Cloud HD on): one row per run, holding a job ID, your account ID, the device you started it from, the sign-in session and the coarse network the request came from (the first blocks of your IP address, never the full address), which tool it was, the options you chose for it (for the restorer, whether you asked for colour), the model ID and model version that processed it, the status (queued, running, done, failed or expired), an error code from a fixed list when it failed, our internal call reference for the server that ran it, a single-use token that ties the result link to your device, the storage keys the input and output briefly occupied, the number of bytes in and out, how many milliseconds it took, how many units it drew and whether it counted as an HD run, what it cost us to run, and the times it was created, started and finished. No image, no filename, no dimensions, and never your full IP address. It is what draws the list on your account page, what the allowance meter counts, and what we would read if you told us a run went wrong.
• Your cloud allowance: your account ID, the calendar month, how many units you have used in it and how many of those were HD runs, and the time the row last moved. One row per month. Nothing else.
• Cloud HD consent records from before 5 September 2026: your account ID, a SHA-256 hash of the exact wording you agreed to, the language you saw it in, the device you agreed on, when you agreed, and whether the statutory cancellation-rights part of it applied to you. Until that date the tools asked for a separate confirmation before your first cloud run; that confirmation is now part of the checkout consent above, so no new rows are written, and the old ones are kept only as evidence of what you were shown. As with the checkout record, we store the hash rather than the text.

What is genuinely not there: your name, your card details, and any image you have ever processed. That last one still holds even with Cloud HD switched on — a Cloud HD photo passes through storage we rent and is deleted, and it is never written into the database described in this section. Paddle holds your card as merchant of record and does not pass it to us. Sign-in codes are emailed to you by Resend on our behalf; Resend sees your email address and the code, nothing else. Until 9 September 2026 a copy of the older licence records also remains in Netlify Blobs while the previous licence system is retired, and it is deleted after that date. It is not dormant in the meantime: as purchases and refunds come in, the payment webhook still mirrors the checkout consent record (keyed to the Paddle transaction ID, and carrying your Paddle customer ID) and any revocation into that older store as well as into Postgres. If you would like a device or session removed, do it from the account page or write to us.

6. Cookies and local storage

We use a small number of cookies and localStorage / sessionStorage items. Every one of them is first-party (set by your browser, scoped to minipx.com only). Separately, the AI tools cache downloaded model files on your device, and those files come from a third party — Section 7 covers that.

Set by MiniPx when you sign in to a Pro account (and only then):

• "__Host-mpx_rt" — your sign-in session. Sent only to minipx.com itself (the name is one the browser only accepts from this exact site), never readable by scripts on the page, never sent to any other site. Lasts up to 30 days, and ends earlier after 7 days without use or when you sign out.
• "__Host-mpx_at" — a short-lived (about one hour) access token derived from the session above, with the same restrictions. Renewed automatically from the session cookie.

Set by Google Analytics (not loaded on the account or activation pages):

• Google Analytics cookies (_ga, _gid, _ga_…) for traffic analysis.

localStorage (persists until you clear it):

• "minipx_consent" — whether you accepted or declined analytics on our own consent banner. Between 8 September and 4 October 2026, while the free tools showed ads, Google's consent message asked instead in the EEA, the UK and Switzerland, and a refusal there was stored here too; since 4 October 2026 MiniPx shows no ads and our own banner asks again. A "denied" stored here means the next page you open sends Google Analytics nothing from its very first moment (section 3). Clearing it, or your site data, withdraws a decline.
• "minipx_session" — a cache of what the account page last showed you: the email address you signed in with, your plan and status, and the device list. It is a copy for display; the source of truth is the server record in Section 5. Cleared when you sign out.
• "minipx_pro_license" — the older Pro licence record (transaction/subscription ID, plan, expiry). Left over from before accounts; the site no longer relies on it and deletes it once your account has confirmed your plan.
• "minipx_ec_era" — a single timestamp marking when your current license entitlement began. Used to work out whether an offline grace period still applies. Only set if you purchase Pro.
• "minipx_device_fp" — a random UUID used to bind your Pro license to this device (anti-piracy). Not used for analytics or tracking. Created on every visit, Pro or not. This is the identifier that appears in the activation records described in Section 5.
• "minipx_saved_presets" — your saved tool settings if you use the Pro Saved Presets feature. Plain JSON, sits only on your device.
• "minipx_theme" — your dark/light mode preference.
• "minipx_ai_quota" — a count of how many free AI-tool runs you have used and, if you have used them all, when the tools unlock again. Four numbers on your device. No image data, nothing about what you processed, and it is never sent to us.
• "minipx_cloud_hd:<tool>" — one key per tool, recording whether you have switched Cloud HD on for that tool in this browser. Off unless you turned it on. It is a preference, not a permission: the server checks your account and your consent record on every run regardless of what this says.
• "minipx_pro_preview_used" — a record of which Pro features you have already spent your one free preview on, so a preview cannot be replayed indefinitely.
• "minipx_passport_stats" — a local counter of passport photos you have generated, used to show your own running total on the passport tool. Counts only, no images.
• "minipx_first_touch" — your first-ever traffic source (referrer, UTM campaign, landing page, timestamp). Used to answer "where did this user originally come from?" in our analytics, without ever identifying you personally.
• "minipx_pro_first_use_pending" — a one-shot flag marking that you have just activated Pro but not yet used a Pro feature, so the "first use" event fires once and only once. Previous versions of this policy listed this as sessionStorage. That was wrong: it is localStorage, and it survives closing the tab.
• "minipx_purchase_fired_txn" — the transaction ID of a purchase whose conversion event has already been sent, so the same purchase is never counted twice. In localStorage because the tab that pays is not always the tab that lands on the activation page.
• "minipx_purchase_pending" — set only when you buy Pro. Holds the amount, currency and plan of the transaction just completed so the activation page can report the sale at its real value instead of at zero. The activation page deletes it as soon as it has either sent that report or established the sale was already counted. If you never return to the activation page it stays on your device until you clear site data.

sessionStorage (cleared when you close the tab):

• "minipx_pending_consent" — set only when you buy Pro. Holds the confirmation wording you agreed to at checkout so the activation page can offer you a copy to download. Cleared once you download it, or when you close the tab.
• "minipx_session" — a random per-tab session ID + last-touch attribution.
• "minipx_pro_score" / "minipx_pro_score_meta" / "minipx_pro_score_emitted" — composite Pro engagement score (0–10) and metadata for this tab session only. Lets us emit one summary event per session rather than dozens of individual events.
• "minipx_session_start_fired" — a one-shot flag that gates the "session started" event.
• "minipx_purchase_fired_txn" — a per-tab copy of the marker described under localStorage above, kept so a tab still running a previous version of the site reads the same value.
• "mpx_first_upload_ts", "mpx_first_value_fired" and "mpx_churn_…" flags — funnel timing markers. They record when you first added a file this session and which funnel milestones have already reported, so each fires once rather than repeatedly. Timestamps and one-shot flags, nothing about the file.
• "mpx_chunk_reload_at" — the time of the last automatic page reload after a failed script download, so a broken deploy cannot put your browser into a reload loop.

Cache Storage and IndexedDB (AI tools only):

• Cache Storage "minipx-ai-models-v1", with IndexedDB database "minipx-models" as a fallback where Cache Storage is unavailable. These hold the AI model files themselves so a model is downloaded once rather than on every use. Depending on which AI tools you use this can reach roughly 160 MB on your device. They contain model weights only — no images, and nothing about what you processed. Clearing site data removes them, and the tools will simply download again next time.

No session replay tools. No fingerprinting. No advertising cookies — MiniPx shows no ads (section 6A).

6A. No advertising

MiniPx shows no advertising, on the free tools or on Pro. Since 4 October 2026 no page loads an ad script, sets an advertising cookie, or sends anything to an ad network, and the browser extension never carried ads.

Until 4 October 2026 the free tools showed ads served by Google AdSense, and in the EEA, the UK and Switzerland Google's consent message asked before any were shown. An advertising cookie Google set during a visit before that date belongs to Google and expires on Google's own schedule; you can remove it by clearing your browser's site data, and Google's Ads Settings still control how Google uses it.

Your image files never reached an ad vendor at any time: no ad vendor ever received a file, a filename, or a pixel.

7. AI model downloads (third-party)

The AI-powered tools (background removal, upscaling, face detection) run the model on your device, but the model file has to get there first. We do not host these files. The first time you use one of those tools your browser downloads it directly from huggingface.co (Hugging Face, Inc.) or storage.googleapis.com (Google Cloud Storage, serving Google's MediaPipe models).

Be clear about what that means, in both directions. Those hosts see what any web server sees when your browser requests a file from it: your IP address, your user agent, and which model file you asked for. That is a third-party disclosure and, because those hosts are outside the EEA and UK, an international transfer. It is covered in Section 12.

What they do not see is your image. The request goes one way — the model comes to your device, your file never goes to theirs. Nothing about the image, its name, its size, or its contents is part of that request, and once the model is cached (see Section 6) no further request is made at all. If you never open an AI tool, this download never happens.

Their handling of the request is governed by their own policies: huggingface.co/privacy and policies.google.com/privacy.

8. Server logs

The site is hosted on Netlify. Netlify keeps standard server logs of HTTP requests (IP address, user agent, requested path, response code, timestamp) for security and abuse prevention. These logs are not sold or shared and are rotated regularly. See netlify.com/privacy for their data handling.

9. Lawful basis for processing

Under the GDPR and UK GDPR we have to name the legal ground for each thing we process, not just describe it. Here they are, one per purpose:

• Analytics — consent, Article 6(1)(a). In the EEA, the UK and Switzerland, Google Analytics does not set an analytics cookie or store any analytics identifier on your device until you accept it — on our own consent banner, recorded in "minipx_consent" (between 8 September and 4 October 2026, while the free tools showed ads, Google's consent message asked instead; section 6A). Before you have answered, your browser can still send Google a cookieless signal that carries no identifier and is not stored against you — this is Google Consent Mode v2, the standard way sites ask before tracking without going dark for every visitor in between. Once you decline, even that stops: nothing is sent to Google Analytics at all, on that page from the moment you decline and on every later page (section 3). You can withdraw consent at any time — from the "Privacy & cookie settings" link in the footer, which reopens our banner, by clearing the "minipx_consent" key from site data, or by writing to us — and withdrawal is as easy as giving it. Withdrawing does not undo processing that already happened lawfully.
• License validation and device binding — performance of a contract, Article 6(1)(b). If you have bought Pro, checking that your license is valid is simply how we deliver what you paid for. The device cap has an additional ground: our legitimate interest in preventing one license being shared across unlimited devices, Article 6(1)(f). We think that is a fair balance because the identifier is random, generated by your own browser, tied to nothing else about you, and the alternative — requiring an account — would mean holding more of your data, not less.
• Cloud HD runs — performance of a contract, Article 6(1)(b). If you have paid for Pro and asked us to run a job on our server, running it is how we deliver what you bought. Two things follow that are worth saying plainly. The box you tick at checkout is not the legal basis for the processing — it is a consumer-rights waiver about your right to cancel, which since 5 September 2026 names Cloud HD runs alongside Pro downloads (until that date a separate box was asked before your first cloud run; it is gone, and the records it produced are kept only as evidence). The plain-text line beside each run control is a statement of what is about to happen, which is a different thing again. And the security work around a cloud run — binding it to a device you have already signed in on, asking for a fresh sign-in code at your first cloud run in a while, watching for a burst of runs from a device we first saw an hour ago — rests on our legitimate interest in not having a paid account used to burn through somebody else's money, Article 6(1)(f).
• Checkout consent records — legal obligation, Article 6(1)(c), together with legitimate interest, Article 6(1)(f). Consumer law requires us to be able to show what you were told about your cancellation rights before you paid, and the same record is what we would rely on in a payment dispute.
• Server logs and rate limiting — legitimate interest, Article 6(1)(f), in keeping the site available and the license endpoint from being abused. Security logging is expressly recognised as a legitimate interest in Recital 49.

Under India's Digital Personal Data Protection Act 2023 the equivalents are: analytics runs on your consent under section 6, and license validation, fraud prevention and security fall under the legitimate-uses provisions in section 7 for data you voluntarily provided for that purpose. Where the DPDP Act requires consent, the notice you are reading is the notice required by section 5.

10. How long we keep things

Previous versions of this policy did not state retention periods at all. They should have. These are ours:

• Account, entitlement, device and revocation records — kept while the purchase is active, then for 12 months after it ends. The tail exists because refunds, chargebacks and reactivations arrive after the fact, and because deleting a revocation record would quietly resurrect a cancelled purchase.
• Sign-in sessions — a session stops working once it expires (7 days unused, 30 days at most), and ending one from the account page deletes its record there and then. Expiry itself is not a deletion: an expired session's record is removed the next time that browser tries to use it, so a browser you simply never open again leaves its row — the start and last-used times, the user agent and the IP — in place until it is removed by hand. We would rather say that than describe a nightly clean-up we do not run.
• Tool usage counts — kept while the license is active, then for 12 months after it ends, the same tail as the activation record and for the same reason: a refund or dispute can be raised after the fact.
• Cloud HD photos — deleted on completion, and in all cases within 24 hours. Section 2A sets out the four separate mechanisms that make that true, and the shorter rule for passport and ID photos, which are deleted the moment the run completes.
• Cloud HD run records, allowance counts and consent records — kept while the subscription is active, then for 12 months after it ends, the same tail as the account records above and for the same reason. Deleting your account removes them immediately; the 12-month tail is applied by hand until a scheduled clean-up exists, and we would rather say that than describe a job we do not run. The consent record is the exception and follows the 6-year rule below, for the same reason the checkout consent record does: it is the evidence of what you were told.
• Checkout consent records — 6 years. This is the one long period in the list, and it is not for our convenience: card networks and payment providers allow disputes to be raised long after purchase, and a consent record we have already deleted is a record we cannot use to defend you or ourselves.
• Rate-limit counters — minutes to a day. They live in time buckets that stop being read once the window passes, and are keyed to hashes, not to your address.
• Paddle webhook event IDs — 10 minutes.
• Google Analytics — held by Google for the retention window configured on the GA4 property. GA4 caps user-level and event-level retention at 14 months; aggregated reports persist at Google beyond that, but cannot be resolved back to a session.
• Netlify server logs — rotated on Netlify’s own schedule, which we do not control. See their policy linked in Section 8.
• Everything in your browser (Section 6) — until you clear it. We cannot delete it for you, and we cannot read it either.
• Advertising cookies — none since 4 October 2026. Any Google set before then expire on Google's schedule (section 6A); we hold nothing.

11. Your rights under GDPR, UK GDPR and the India DPDP Act

You have the right to:

• Know what data we hold about you and get access to it (Article 15). In practice: very little, see above.
• Have inaccurate data corrected (Article 16).
• Have your data erased (Article 17). For anything in your browser you can do this yourself in one step by clearing site data.
• Restrict processing (Article 18) — ask us to keep the data but stop using it, for example while a dispute over accuracy is being sorted out.
• Data portability (Article 20) — receive the data you gave us, or that we hold on the basis of consent or contract, in a structured, commonly used, machine-readable format. For MiniPx this means your activation record and your checkout consent record; we will send them as JSON.
• Object to processing based on legitimate interest (Article 21), including our device-binding and security processing. Tell us why and we will stop unless we can show compelling grounds that override your interests.
• Withdraw consent for analytics at any time, with no effect on the lawfulness of what happened before you withdrew.
• Lodge a complaint with your local data protection authority — in the UK the ICO, in the EEA your national authority, in India the Data Protection Board.

Automated decision-making. We do not make decisions about you by automated means that produce legal effects or similarly significantly affect you, and we do not profile you. The one automated rule worth naming so you can judge it yourself: if a Pro license is presented from more devices than the plan allows, the extra device is refused, and repeated attempts from many different devices within an hour can cause the license to be revoked. That is a license-enforcement rule applied to a key, not a judgement about a person, and a human will review it if you ask — write to us and we will restore access if the pattern was innocent.

Cloud HD is automated, and it decides nothing about you. A photo goes to a server, a model transforms it, a photo comes back. There is no scoring, no classification of you or of anyone in the picture, no face recognition, no comparison against any other photo, and no record derived from your face — the models measure pixels, not people. Nobody reviews the image, and no result of a cloud run changes what you pay, what you can access, or how we treat you. One check deserves naming precisely because this paragraph exists: the photo-restoration tool measures whether the restored face still matches the face in the photo you sent — a similarity check between our output and your input, on that run alone. It never compares your face against anyone else’s or against any database, and the run record keeps no measurement of your face — at most a code saying the check refused the result, in which case you are not charged. Beyond that, the rules that can refuse a run are usage limits and security checks — the monthly allowance, an hourly ceiling, a daily cap on failed runs, and a fresh sign-in check — and none of them judges you or your photo: when your allowance is used up, the tools say so until the month resets, and your device keeps working as before.

India DPDP Act 2023 — additional rights. Section 13(3) requires us to publish the contact details of a person who can answer your questions about processing. Section 14 gives you the right to nominate another individual to exercise your rights on your behalf if you die or become incapacitated. To nominate someone, write to us with their name and contact details and we will record it against your license.

Grievance Officer: Gaurav Bhowmick, the sole proprietor who operates MiniPx and is named in Section 1. For a sole proprietorship the proprietor is the responsible individual under section 13(3). Grievances under the DPDP Act should be sent to contact@minipx.com, which is monitored by the operator named in Section 1. We aim to respond within 7 days and will not exceed the statutory response periods.

To exercise any of these rights, email contact@minipx.com. For Pro purchases, you can also exercise these rights through Paddle directly.

12. International transfers

Google Analytics processes data in the United States. Paddle processes payment data in the United Kingdom, the United States, and the European Union. Supabase, Inc. hosts the account database described in Section 5 in the United States (AWS us-east-1). Resend, Inc. sends sign-in emails from the United States. Netlify hosts the site and runs our account endpoints from a global infrastructure footprint. All five are covered by standard contractual clauses or equivalent transfer mechanisms.

Cloud HD adds two more, and they are the only ones that ever handle an image. Cloudflare, Inc. stores the photo for the seconds or minutes it exists, and Modal Labs, Inc. runs the model on it. Both process it in the United States, which is why we say your photo is processed in the United States rather than something vaguer. The transfer runs on the European Commission’s standard contractual clauses, Module 2, the module for a controller sending data to a processor, and we have a data processing agreement with Modal that includes audit rights and requires them to tell us about a security breach without undue delay. We do not rely on the EU-US Data Privacy Framework as our main mechanism: the clauses stand on their own and do not depend on an adequacy decision surviving a court challenge. Separately from Cloud HD, the sign-in pages (/account/ and /activate/) and the re-authentication prompt on the Cloud HD tools load Cloudflare Turnstile, a bot check run by Cloudflare, Inc.: as soon as one of them opens, it receives your IP address and information about your browser and device, which Cloudflare uses to tell a person from an automated script, under Cloudflare’s own privacy policy: cloudflare.com/privacypolicy.

The AI model hosts described in Section 7 are a fourth transfer, and it is worth naming separately because it is the one that happens without any account or purchase. Hugging Face, Inc. is based in the United States, and storage.googleapis.com is operated by Google. When your browser downloads a model file, your IP address and user agent reach a server outside the EEA and UK. We do not have a data processing agreement with Hugging Face covering this, because we are not sending them your data — your browser is requesting a public file, in the same way it would from any public CDN. If that transfer is not acceptable to you, do not use the AI tools; every other tool on MiniPx works without it.

13. Children

MiniPx is a general-purpose utility, not a service targeted at children. We do not knowingly collect data from anyone under 13 (or under 16 in the EU). If you believe a child has provided us with data, write to contact@minipx.com and we will delete it.

14. Changes to this policy

We update this policy when our practices change. When we do, we update the "Last updated" date at the top and, for material changes, we email every account holder at the address on their account.

15. Contact

For any privacy question, write to contact@minipx.com. We aim to respond within 7 days.