Privacy Policy

1. Who we are

Convertlix is operated by Convertlix ("we", "us"). For questions about this policy, or to exercise any right described in section 8, write to contact@convertlix.com. We answer within 30 days, and in every case within the one month that UK and EU data-protection law allows — and within the 90 days that India's Digital Personal Data Protection Rules allow, where those apply.

2. The short version

• Your files are never uploaded. Conversion, OCR, compression and metadata editing all happen on your device. The first successful sign-in needs a connection; after that, conversion continues in airplane mode.
• We do not sell or share your data with anyone for advertising, profiling or any other purpose beyond running the service.
• There is no advertising SDK and no cross-app tracking in the app, and nothing we collect is used to target an advertisement anywhere. There is product analytics: the app records which features you use and sends that to our own servers. Section 4.5 is the full account, and section 8.1 is how to object to it.
• An account is required. There is no guest mode or skip. Once you have signed in successfully, the local sign-in marker does not expire and the tools keep working offline.
• We never store your email address in readable form in our database — only a keyed hash for lookup and an encrypted copy whose key is held elsewhere.
• You can delete your account and its data from inside the app, or on the web at https://www.convertlix.com/delete-account.

3. What the app processes on your device, and never sends

These stay on your handset in every case:

• The files you select, their contents, their names and their metadata.
• The converted output, saved where you told the app to save it.
• Text recognised by OCR. The recognition models are bundled inside the app; no page image or extracted text is transmitted.
• Camera frames captured by Cam to PDF, including the live preview used to find the edges of the page. They are processed in memory, written only to the PDF you asked for, and never transmitted.
• Signature images you place with Sign PDF.
• Your conversion history and favourites, stored in a local database.
• Your settings, including theme, language and save location.

The app requests no storage permission at all. It reaches files only through the system document picker and photo picker, which means you choose each file explicitly and the app can see nothing you did not hand it.

It can request two runtime permissions. The camera is asked for the first time you open Cam to PDF and used for nothing else; decline it and every other tool keeps working. Notifications may be asked once after sign-in so the app can show account messages, important product updates and — for a finite Premium plan — one reminder in the final five days of a paid period. Declining changes neither Premium nor conversion. No photo or video is stored outside the document you create, and none is uploaded — there is no upload endpoint to send one to.

None of this changes because of the analytics in section 4.5. An analytics event records that you ran a particular tool and how it ended. It does not carry the file name, the file path, the file type, the file contents, a hash of them, or any text found inside them — and our server refuses to store such a value even if a future version of the app were to send one. See the last paragraph of section 4.5.

4. What is sent to our servers

The app contacts https://www.convertlix.com for identity, licensing, quota checks, configuration, analytics, notification registration and payments. It also contacts Google Firebase for push delivery as described in section 4.7. Your file is never part of those calls. After the first successful sign-in, a network failure does not stop local conversion; the cached entitlement and local monthly ledger remain in force.

4.1 Licensing and free-tier limits

We do not collect your advertising ID, IMEI, serial number, MAC address, phone number, contacts, precise location, or ANDROID_ID in raw form. The device identifier is app-scoped and pseudonymous: it cannot be correlated with any other app's data, and uninstalling the app destroys it permanently.

4.2 Your account

An account is compulsory. A new installation must connect for its first successful sign-in; afterwards the app can open and convert offline. We store:

We never hold your password. Signing in and signing up are handled by Clerk (Clerk.com), a specialist identity provider acting as our processor. Your password, if you set one, is created and checked entirely on Clerk's systems and is never sent to us — so there is no password, and no password hash, anywhere in our database. Clerk holds your email address and your credential; we hold the record described above, and the two are joined only by the opaque reference in the table.

Signing in with Google. Android Credential Manager is tried first and a provider-hosted browser flow is the fallback. The app never sees your Google password. Google returns your email address, name and profile picture; we request nothing else — no contacts, no Drive, no calendar. Google's own handling of that interaction is governed by Google's Privacy Policy.

Deleting your account deletes it at Clerk too, and then deletes our record of you. Both are described in section 8.

4.3 Payments

If you buy Premium, the payment is processed on our payment provider’s hosted page, shown in the app or in your browser. Card numbers never touch our app code or our servers. We never receive a card number, a card fingerprint, a bank identification number or a billing address, and we do not record your IP address against an order.

What we do store is a payment reference, which of the two plans you bought, the amount, the currency, the country and the status. Your billing email address is passed to the payment provider so they can send you a receipt. On the checkout record itself we keep only a keyed hash of it — not the address; the address in a form we can read back lives on the licence record, in the same encrypted form as an account email (section 4.2).

4.4 Network metadata

Like every web server, ours sees your IP address when the app calls it. It is used for rate limiting, abuse prevention and — for pricing and checkout — deriving a country-level location. We use country only: never city, region or coordinates. It is not written into your device or account record. On the analytics path it is never even written into a rate-limiting counter in readable form — the counter is keyed on a keyed hash of the address instead, so the address itself exists only for the moment the request is being handled.

We do not store your IP address against your device or account record. To be exact about the one place it does briefly appear: on our other endpoints — activating a licence, requesting a sign-in challenge, fetching configuration, the health and legal endpoints — the rate-limiting counter is keyed on the address itself rather than on a hash of it. Those counters hold nothing but a bucket name and a number of requests. They are not joined to your account, they are not part of any profile, they are never used to build one, and they are deleted automatically within 48 hours. There is no other table in our systems in which your address is recorded.

Our hosting edge normally supplies the two-letter country directly. If a deployment has no such header, we may use a configured HTTPS country-lookup processor for that checkout; it receives the address only to return a two-letter country. Provider lookup is disabled unless we have deliberately configured and approved one. The address and response are not cached or added to an order; only the country may be retained as described above.

4.5 Product analytics — how the app is used

Read this section if you read only one. The app records what you do inside it and sends those records to our servers in batches. This is first-party only: it goes to us, it is not sold, it is not shared with advertisers or data brokers, it is not used to target advertising, and it is not used to follow you across other apps or websites.

What an event carries. Our server accepts a closed list of fields and discards everything else on arrival. That list is:

Why we do it. To keep the app working, to find and fix the conversions that fail, to see which tools are worth building on and which are not, to understand where people abandon sign-up or checkout, to detect abuse of the free tier, and to decide which Android versions and device classes we can stop supporting. That is the whole list.

How long we keep it — 90 days. Every table that carries an identifier of any kind is deleted 90 days after the event. What remains after that is aggregate counts — how many events of a given kind happened on a given day, in a given country, on a given app version — and the sizes of anonymous cohorts. Those counts never contained an identifier in the first place: there is no account column and no install column in them to be left blank or filled in later, which is what makes deleting the raw records genuinely final. We keep the counts.

On what legal basis. In the United Kingdom and the European Economic Area we rely on our legitimate interests (Article 6(1)(f) UK/EU GDPR) in operating, securing, debugging and improving Convertlix. We have written that assessment down rather than merely asserted it. Elsewhere, including in India where Convertlix is established, we process this data on the basis of the notice given to you in this policy and on the app's first-run screen. We are not going to call that consent, because we do not ask for it: the first-run screen tells you what is collected and has a button that continues, and there is no analytics on/off switch in the app. If you want the processing stopped, section 8.1 is the route and we honour it.

And the part that has not changed. Nothing in an analytics event describes a file. No file name, no file path, no file type, no file contents, no hash of them, no page image, no OCR text, and no text you typed. This is not enforced by the app promising to behave: the server holds the list of fields an event may carry, drops any field that is not on it, and additionally refuses any value that even looks like a path, a content:// or file:// address, an email address or a network address. A future version of the app could not send us a file name by accident, because there is nowhere for it to land.

Where an install came from. Our servers will accept, and store against the installation, a small amount of campaign attribution: the marketing source, medium and campaign name that led to the install — values like utm_source=google-play, utm_medium=organic — taken from the referrer string the Play Store provides when the app is first installed. We use it for one purpose: to know which channels bring people who find the app useful, so we can stop paying for the ones that do not. It is not an advertising profile, it is not shared with an ad network, and it describes the install, not you.

Three limits on it are worth stating plainly, because they are enforced in code rather than promised. The raw referrer string is never stored — it is read once, the three campaign fields above are taken out of it, and the original is discarded before anything is written. We do not accept or store a click identifier (the gclid parameter a Google ad appends): our server refuses that field by name, which is consistent with our not collecting an advertising ID. And this data is covered by the same 90-day retention as everything else in this section — it lives on the installation record, which is deleted 90 days after that installation was last seen, and it is removed immediately if you delete your account. At the time of writing the app we ship does not send this at all; the disclosure is here because our server would accept it, and we would rather tell you what we are able to receive than what we currently happen to get.

4.6 Crash reports

When the app crashes, or hits an error it can recover from, it sends a report to Sentry (Functional Software, Inc.), a crash-reporting service acting as our processor. A report contains a technical stack trace, the device model, the Android version, the app version and — if you are signed in — our internal account reference. It does not contain your email address, your IP address, or anything about your files; the SDK option that would otherwise attach personal details is switched off.

Crash reports are retained for 90 days. This applies to the Android app only — there is no crash-reporting service on our own servers.

4.7 Push notifications

After you sign in and allow notifications, the app may ask Firebase Cloud Messaging (a Google service) for an app-installation token. We send that token to our server and associate it with our internal account reference and the verified handset, so an account message can be addressed to the right person. In our database the token is stored as an encrypted value plus a keyed hash; it is never logged and it is not used for quota, advertising, analytics attribution or identifying you in another app.

Google processes the app-installation identifier, the delivery metadata, and the title and body of a notification in order to deliver it. We do not put file names, file contents, email addresses or converted text in a push message. Account-targeted messages carry only our opaque internal account reference, which the app compares with its locally cached account before showing anything. Signing out disables and deletes the local Firebase token and asks our server to remove its encrypted copy; a message already in flight is discarded locally if the account no longer matches.

Firebase may also call its app-installation identifier an FID. We do not use it as the reinstall-resistant device identity described in section 4.1: it can change after reinstall or Clear Data and has no role in licensing or the free allowance.

5. What we do, and what we never do

We do keep a record of how you use the app. An earlier version of this policy said we build no behavioural profile and infer nothing about you from the tools you use. That is no longer accurate, and we would rather delete the sentence than qualify it: the per-install, per-account activity trail described in section 4.5 is a behavioural profile in the sense data-protection law means the phrase. Assume that we can see the order of the things you did in the app. Section 4.5 says exactly what that trail contains, section 7 says how long it lasts, and section 8.1 tells you how to stop it.

What we never do — and each of these is a property of how the system is built, not a promise about our intentions:

• We do not upload, read, index, scan or train on your files. There is no upload endpoint for one to arrive at.
• We do not sell, rent or trade personal data, and we do not "share" it in the specific sense the California Consumer Privacy Act gives that word.
• We do not run advertising, ad networks, advertising SDKs or cross-app tracking, and nothing described in section 4.5 is used to target an advertisement anywhere.
• We do not combine what we hold with data bought from data brokers, or with data about you from any other app or website.
• We do not use your data to train machine-learning models.
• We make no automated decision about you that produces a legal effect or something similarly significant.
• We do not collect your advertising ID, IMEI, serial number, MAC address, phone number, contacts, precise location or ANDROID_ID.

6. Legal bases (UK/EU GDPR)

• Contract — issuing your licence, applying your monthly allowance, processing a purchase, running your account, and delivering notifications you have allowed the app to show.
• Legitimate interests — preventing licence sharing and abuse, keeping the service running, answering support requests, and the product analytics described in section 4.5. The interest is a concrete one: knowing which tools are used, which conversions fail, and where people give up, so that the work goes where it is needed. We have balanced it against your rights by holding identifiers only in pseudonymised form, by collecting no file data at all, by capping how long the records live, and by honouring objections — see section 8.1.
• Legal obligation — retaining transaction records for tax purposes.

Some countries — including India — have no "legitimate interests" basis in their data-protection law. Where that is so, section 4.5 explains plainly what we do and on what footing, and section 8.1 is available to you on the same terms wherever you live. We would rather tell you where the ground is uncertain than claim a basis we have not established.

7. How long we keep things

• Account record — until you delete it. Deletion is immediate and irreversible.
• Device and licence records — while the licence is active, then up to 24 months.
• Individual usage events — 90 days, after which only aggregate daily and monthly counts remain.
• Product-analytics records (section 4.5) — 90 days. That covers the events themselves, the per-sitting and per-day rollups, and the record of an installation including the campaign attribution described in section 4.5. After 90 days what is left is aggregate counts and cohort sizes that never held an identifier, which we keep.
  One record is deliberately kept longer, and it is the one that makes deletion work. When you sign in, we store a link between the installation and your account. That link is what lets us find the activity recorded before you signed in, so that deleting your account deletes it too. If we removed the link on a flat 90-day clock we would still hold those earlier records and would no longer be able to tell they were yours — they would survive the deletion you asked for, which is the opposite of the intent. So the link is kept for as long as there is any activity it can still identify, and it is deleted as soon as the last of that activity ages out — or immediately, along with everything else, if you delete your account. It holds nothing but the two identifiers and the date it was created.
• Crash reports — 90 days, held by Sentry.
• Push-notification token — while this signed-in installation is active. It is removed on sign-out, account deletion, a permanent rejection from Firebase, or automatically after 90 days without a registration heartbeat. Opening the app again registers the current token.
• Operator audit logs — 400 days. This one is not a record of you. It is our internal log of administrative access to the staff panel: which member of our team signed in, what change they made, and to which record. It holds their work email address and the IP address they acted from, not your activity, and nothing in it is written by anything you do in the app.
  It is kept longer than the 90 days above for a specific reason. The other windows cover data whose usefulness fades quickly. An access log exists for the opposite case — establishing, after the fact, who did something — and questions of that kind are usually asked late: an account is found to have been compromised months afterwards, or someone asks us to account for a change made last year. A window shorter than a full annual cycle would mean the record was routinely gone before anyone had cause to look for it, which would leave us unable to answer the very questions you are entitled to ask us. So the log is held for a year plus a margin, then deleted automatically.
  Two consequences are worth stating plainly. It does not extend how long we keep records about you — every window above is unchanged, and this entry adds nothing about your activity to any of them. And where one of these entries names you, because a member of our team acted on your account at your request or under section 8, that entry records the action taken and the record it applied to rather than anything about how you use the app.
• Purchase records — as long as tax law requires, typically 7 years. These hold no readable email address and no device identifier.
• Rate-limit counters and sign-in nonces — hours, then purged.
• Objection and deletion markers — kept indefinitely, on purpose. When you object under section 8.1, or delete your account, we write a small record holding only the pseudonymous identifier to be suppressed and the date it was set. It has no expiry, and it has to outlive everything else: a suppression marker that lapsed would quietly start collecting again, which is the opposite of what you asked for. We remove one in two situations only — we recorded the wrong person by mistake, or you tell us yourself that you want us to start again. Your objection does not expire, and we will never lift it on our own initiative.

8. Your rights

You can, at any time and without giving a reason:

• Delete your account and everything personal in it — from Settings → Account → Delete account in the app, or on the web at https://www.convertlix.com/delete-account. This is a real deletion, not a flag. It removes the analytics trail as well as the account, including the activity recorded on your devices before you signed in, and it happens as part of the deletion itself rather than on a later sweep.
• Object to analytics without deleting your account — section 8.1.
• Get a copy of your data, or ask us to correct it, by writing to contact@convertlix.com.
• Restrict processing based on legitimate interests, and withdraw consent where we rely on it.
• Complain to your data-protection authority. In the UK that is the Information Commissioner's Office; in the EEA it is the supervisory authority where you live; in India it is the Data Protection Board of India.

Deleting your account signs this installation out, so the tools require a new account sign-in before they can be opened again. It does not delete any converted file — those are on your device and were never ours.

9. Children

Convertlix is not directed at children under 13, and we do not knowingly collect data from them. If you believe a child has created an account, write to contact@convertlix.com and we will delete it.

10. Where data is processed, and who processes it

We use a small number of service providers, each acting on our instructions under a data-processing agreement, and none of them is permitted to use your data for its own purposes:

These providers may process data outside your country. Where the UK or EU GDPR applies, transfers rely on the UK IDTA or the EU Standard Contractual Clauses.

11. Security

All traffic between the app and our servers is TLS-encrypted. Device identifiers, install identifiers, push tokens and email addresses are pseudonymised or encrypted at rest with keys held outside the database. We store no password and no password hash at all — the credential lives with Clerk, and what our server checks is a short-lived, cryptographically signed token Clerk issues. Entitlements are signed with Ed25519 and verified on your device against a key compiled into the app, which is why a compromised network cannot change what you are entitled to. No system is perfect; if you find a vulnerability, please report it to contact@convertlix.com with "SECURITY" in the subject and we will credit you.

12. Changes

If we change this policy in a way that materially affects you, the app will tell you before the change takes effect. The date at the top always reflects the current version.

13. Contact

Convertlix — contact@convertlix.com

For data-protection matters specifically — a copy of your data, a correction, an erasure, or an objection under section 8.1 — use contact@convertlix.com. We answer within one month, and within the 90 days allowed by India's Digital Personal Data Protection Rules where those apply.