/privacy
How ZANCTA handles privacy.
Last updated: August 25, 2026. ZANCTA is independently operated privacy-first document software. Supported tools process selected files in the browser. This page describes current product behavior.
Local file processing
For supported local PDF and image tools, selected file bytes are read and processed in the browser. ZANCTA does not receive those bytes for processing. Background removal runs on a small segmentation model downloaded once from ZANCTA itself and cached by the browser — the model and engine load from this site, but image bytes are not sent to any service.
That file-byte boundary is not a claim that ZANCTA collects no data. Accounts, email, optional analytics consent, security and audit records, and the other categories on this page are separate from selected file bytes.
This boundary does not control browser extensions, malware, operating-system backups, device sharing, or future features that are explicitly offered as optional cloud services.
Account information
If you create an account, ZANCTA stores information needed for sign-in and plan access, such as your email address, optional name, password hash, sessions, verification links, and password-reset links. Passwords are not stored in plain text.
If you sign in with Google or GitHub, the application may also store the name and profile image those providers supply, and OAuth account records needed to complete sign-in, including tokens the identity provider issues for that authentication. Public Sign in with Google does not grant ZANCTA access to Google Analytics or Google Search Console. Public GitHub sign-in is likewise only for authentication. Those public login paths are separate from the ADMIN-only operator integrations described below.
Cookies and browser storage
Essential and security cookies are used for authentication (session, CSRF, OAuth state/PKCE) and, when you start Google or GitHub from Sign in or Sign up, a short-lived OAuth intent cookie. When the site operator starts a Google API or Bing Webmaster connection from the ADMIN dashboard, a short-lived httpOnly operator OAuth cookie is used to complete that connection. Those cookies are required for the account or operator connection to work and are not advertising cookies.
A consent preference may be stored in localStorage so we remember whether optional analytics is allowed. Local tool results stay in the browser session for preview or download and are released when you leave or clear that workspace.
Analytics and advertising
No advertising network is enabled. An ad-delivery layer exists behind a disabled feature flag for a possible future launch; while disabled it renders nothing and loads no third-party code. If advertising is ever enabled, it will be clearly labelled, kept away from tool controls and download flows, and withheld from active Premium accounts. This page will be updated before any ad provider script loads.
Google Analytics (GA4) loads only if a measurement ID is configured and you choose Allow analytics. Client events may include page_view, tool_view, tool_used, processing_started, processing_completed, processing_failed, processing_cancelled, download_completed, pricing_view, and related product events. Payloads are limited to tool slugs, language codes, and similar non-content fields. The product does not send file bytes, filenames, extracted PDF text, OCR output, email addresses, or payment details. Billing events are recorded server-side. There is no ads.txt file because ads are not authorized to sell this inventory. This optional measurement tag is separate from the site-operator Google Analytics API access described below. The measurement script is loaded from Google Tag Manager's gtag endpoint when consent is granted; fonts used by the site are served from ZANCTA itself, not from a Google Fonts CDN.
Google API Data — Site Operator Integrations
This section applies only to ZANCTA's site-operator (ADMIN) functionality. It does not apply to ordinary Free or Premium ZANCTA users, and it is not part of public Sign in with Google.
Public Sign in with Google is a separate authentication path. It lets a person create or sign in to a ZANCTA account. Ordinary ZANCTA users who sign in with Google do not grant ZANCTA access to Google Analytics or Google Search Console.
When an authorized ZANCTA site operator connects Google services from the ADMIN dashboard, ZANCTA may access Google API data required to operate those connected integrations. That data is used only to provide the operator/admin integrations and related operator dashboards inside ZANCTA. ZANCTA does not use this Google API data for advertising, to profile ordinary ZANCTA users, or to sell data.
Google account identification. The operator connection may use basic Google identity information, such as the connected account's email address and Google account identifier, to show which Google account is connected.
Google Analytics 4. The operator integration may access Google Analytics data needed for the ZANCTA admin analytics dashboard. That can include Analytics account and property information used to identify the connected property, property configuration metadata used by the dashboard, and reporting data such as aggregated users, sessions, events, pages, countries, devices, and similar breakdowns, including a limited realtime active-users view where the dashboard requests it.
Google Search Console. The operator integration may access Search Console information needed for the ZANCTA admin dashboard, including verified properties or sites visible to the connected account, search performance data (for example queries, pages, countries, devices, and related totals), URL inspection results for URLs the operator inspects through the dashboard, sitemap listing information, and submission of ZANCTA's canonical sitemap URL to Search Console.
Who can access this data. These Google API integrations are ADMIN/operator functionality. They are not available to ordinary Free or Premium ZANCTA users. Google API data retrieved for the operator dashboard is not exposed as another user's public account data. The public Google sign-in flow is separate from this operator Google API integration.
Storage and security. OAuth access and refresh tokens required for the operator Google integration are stored encrypted at rest using ZANCTA's server-side encryption. Cached dashboard snapshots of retrieved Google API responses may also be stored so the admin dashboard can display recent results.
Sharing. ZANCTA does not sell this Google API data and does not share it with third parties for their independent use. The data is requested from Google's APIs and used inside ZANCTA's operator tools. Google continues to process the underlying Analytics and Search Console data under Google's own terms.
Disconnect and retention. The operator can disconnect the Google integration from the ZANCTA admin interface. When that happens, ZANCTA attempts to revoke the current Google access token with Google, then clears stored access and refresh tokens and related Google account identity fields from the operator connection record, marks the connection as disconnected, and deletes cached Google dashboard snapshots. The connection record itself is kept in a disconnected state; some non-secret property identifiers used to select Analytics or Search Console properties may remain on that record. Operational audit entries that a connection, disconnection, or sitemap submission occurred may be retained; a connection audit entry may include the connected Google account email. Disconnecting Google in the admin interface is separate from deleting a ZANCTA user account; deleting a ZANCTA account does not, by itself, disconnect the operator Google integration.
Revocation by the Google account holder. The connected Google account can revoke ZANCTA's access in Google's account permissions. After revocation at Google, ZANCTA cannot continue calling those Google APIs with the previous authorization. ZANCTA cannot control Google's copy of Analytics or Search Console data.
Bing Webmaster is a separate ADMIN-only operator integration and is described in Bing Webmaster — Site Operator Integrations.
Bing Webmaster — Site Operator Integrations
This section applies only to ZANCTA's site-operator (ADMIN) functionality. It does not apply to ordinary Free or Premium ZANCTA users, and it is not part of public Google or GitHub sign-in.
When an authorized ZANCTA site operator connects Bing Webmaster from the ADMIN dashboard, ZANCTA uses Bing Webmaster OAuth with the webmaster.manage permission so the operator dashboard can manage the connected site. A short-lived httpOnly cookie named zancta_op_oauth_bing is used to complete that connection. It is not an advertising cookie.
ZANCTA stores an operator connection record with encrypted access and refresh tokens and the selected site URL. The operator dashboard may retrieve Bing Webmaster data needed to operate that integration, including the connected account's site list, query and page statistics, crawl information, sitemap or feed information, related keywords, URL-submission quota, and URL submission for the selected site. That data is used only to provide the operator Bing dashboard inside ZANCTA. ZANCTA does not use this Bing Webmaster data for advertising, to profile ordinary ZANCTA users, or to sell data.
Bing dashboard results are currently retrieved from Bing when the operator opens the dashboard rather than stored as cached dashboard snapshots. Cached snapshots are used for the Google operator integration described above. On Bing disconnect, ZANCTA still deletes any snapshots stored for that provider.
These Bing Webmaster integrations are ADMIN/operator functionality. They are not available to ordinary Free or Premium ZANCTA users. Bing data retrieved for the operator dashboard is not exposed as another user's public account data.
OAuth access and refresh tokens required for the operator Bing integration are stored encrypted at rest using ZANCTA's server-side encryption. The operator connection is not part of an ordinary user account record.
ZANCTA does not sell this Bing Webmaster data and does not share it with third parties for their independent use. The data is requested from Bing Webmaster APIs and used inside ZANCTA's operator tools. Microsoft/Bing continues to process the underlying Webmaster data under its own terms.
The operator can disconnect Bing from the ZANCTA admin interface. When that happens, ZANCTA clears stored access and refresh tokens and related connection fields, marks the connection as disconnected, and deletes any cached snapshots for that provider. ZANCTA does not currently send a Bing-side token revocation request. The connected Bing/Microsoft account can revoke ZANCTA's access in that account's permissions. After revocation there, ZANCTA cannot continue calling those APIs with the previous authorization. ZANCTA cannot control Bing's copy of Webmaster data. Operational audit entries that a connection, disconnection, or URL submission occurred may be retained. Disconnecting Bing in the admin interface is separate from deleting a ZANCTA user account; deleting a ZANCTA account does not, by itself, disconnect the operator Bing integration.
Contact form
The Contact form collects name, email, topic, subject, message, and an optional account email if you provide one. ZANCTA uses this to route the enquiry to the matching mailbox and to reply. Submissions are sent through the email service currently handling delivery, either Hostinger Mail or Resend: a notification to ZANCTA and an acknowledgement to you. Contact submissions are not stored as a ZANCTA application database record. The configured email provider may retain copies according to its own practices; ZANCTA does not currently delete those provider copies. Contact submissions are subject to rate limiting that may use IP address and email-derived identifiers for abuse prevention.
Transactional email
Transactional email is delivered by Hostinger Mail or Resend. Messages can include email verification, password reset and password-change confirmation, welcome, account-deletion confirmation and notice, contact acknowledgement and a notification to ZANCTA, and billing notices when the payment service reports a subscription, payment, cancellation, or refund update. The configured email provider processes the recipient address and message content for delivery and may retain copies according to its practices.
Payments and email
When purchasing is available, Dodo Payments handles checkout and billing as Merchant of Record. ZANCTA does not store card data. Dodo Payments receives the information needed to process payment, and ZANCTA may store billing records such as customer and subscription identifiers, amounts, currency, and status. See Refunds and cancellation.
Security, audit, and rate limiting
For security, abuse prevention, rate limiting, auditing, and troubleshooting, ZANCTA may record operational events such as account creation, verification, password reset, account deletion, payment checkout or cancellation actions, and operator integration connect or disconnect. Those records can include IP address and, in some cases, browser user-agent.
Production rate limiting uses Upstash Redis and may process identifiers such as IP address and, where applicable, email-derived rate-limit data. Rate-limit entries expire after the applicable rate window.
Application audit records are not currently subject to an automatic purge job. They are retained as necessary for the purposes described above and subject to applicable operational, security, legal, and provider retention requirements.
Hosting and processors
ZANCTA is hosted on Vercel. Vercel provides application delivery and may process request metadata, such as IP addresses, as part of hosting and request infrastructure. Application database records described on this page are stored in PostgreSQL hosted by Supabase. Selected PDF and image file bytes for supported local tools are not sent to Vercel or Supabase for tool processing.
Service providers currently include: Vercel (hosting and request infrastructure); Supabase PostgreSQL (account and application records); Hostinger Mail or Resend (transactional and contact email); Upstash Redis (rate limiting and abuse prevention); Dodo Payments (payments and Merchant of Record when purchasing is available); Google (public authentication, optional consented analytics, and protected site-operator connections described above); GitHub (optional public authentication); and Bing Webmaster (the protected site-operator connection described above).
Retention and deletion
ZANCTA does not retain selected file bytes from supported local tools.
Account deletion removes your ZANCTA profile and associated account data. If Premium is active, ZANCTA first attempts to schedule cancellation at period end; if cancellation cannot be confirmed, the account is not deleted. Removed data includes sessions, connected sign-in records, plan access, verification and password-reset records, account-deletion codes, and related ZANCTA billing records.
Account deletion does not erase every related record. Payment records may remain without a user identifier for billing reconciliation, and payment-notification records may remain. Security records may remain with your user identifier removed. ZANCTA may retain a protected record of a deleted Google or GitHub sign-in identity so that it cannot silently recreate an account. Site-operator Google and Bing connections are separate from ordinary customer accounts and are managed through protected administration controls.
Verification links expire after 24 hours, password-reset links after 60 minutes, and account-deletion confirmation codes after 15 minutes. Abuse-prevention data expires with the applicable rate window. Security, payment-notification, and deleted-identity records do not currently have an automatic deletion schedule. Other records without a fixed expiry are retained as necessary for the purposes described on this page and subject to applicable security, legal, and provider requirements.
Dodo Payments retains customer, payment, subscription, and checkout records as Merchant of Record; ZANCTA cannot delete those provider records. Hostinger Mail, Resend, Google, GitHub, Bing/Microsoft, Vercel, Supabase, and Upstash may retain their own copies according to their practices. ZANCTA cannot necessarily delete those provider-side copies. Google API tokens and snapshots used by the site-operator integration are handled as described in Google API Data — Site Operator Integrations, including on disconnect. Bing Webmaster tokens are handled as described in Bing Webmaster — Site Operator Integrations.
International users
ZANCTA is reachable worldwide and prices only in Indian rupees, with no EU-specific domain, language, or marketing. Under the General Data Protection Regulation and UK GDPR, a non-EU/UK site is generally reached only where it intentionally targets EU/UK-based visitors, not merely because the site is accessible from there. Based on that standard, GDPR/UK GDPR do not currently appear to apply to ZANCTA; that assessment would need to be revisited if EU/UK-directed pricing or marketing is introduced.
The California Consumer Privacy Act and its amendments apply only to businesses meeting a revenue or data-volume threshold (broadly, over roughly $26 million in annual revenue, or buying/selling/sharing personal information of 100,000 or more California consumers or households in a year). ZANCTA, as an individual-operator product at its current scale, does not appear to meet any of those thresholds.
Contact for privacy questions
Privacy questions: privacy@zancta.tech. Support: support@zancta.tech. Security: security@zancta.tech. Self-service pages: Help, Contact, Security. The operator is identified in Terms.
India's Digital Personal Data Protection Act, 2023 and its 2025 Rules (MeitY) were notified on a staggered timeline. The substantive Data Fiduciary obligations — including Rule 9, which would require publishing contact information for a person who can answer questions about personal-data processing — are not yet in force; the government's notification sets their commencement 18 months after notification, in mid-2027. Publishing privacy@zancta.tech as the privacy contact today is a voluntary step taken ahead of that date, not a claim of present-day statutory designation. No Data Protection Officer is designated.
Next steps