EditMyPDF Privacy Policy

Last updated: March 24, 2026

Summary

EditMyPDF is a document editing and transformation service, with a primary focus on PDFs. The service includes document editing, AI-assisted document workflows, OCR, file conversion, metadata editing, splitting, and cloud import/export features. Some features may be used without creating an account; other features require authentication or a paid subscription.

To provide the service, we process several categories of data, including account data, uploaded files and documents, prompts and instructions, generated outputs, subscription and payment data, technical and security data, and optional analytics or advertising data where consent is required.

Strictly necessary technologies remain active because they are required for the core operation and security of the service. Optional analytics and advertising technologies are off by default unless and until you provide the required consent. You can manage your preferences at any time via our /cookies page or the preference center made available on the site.

When you use AI-powered or document-processing features, the content you provide may be processed by EditMyPDF and, where necessary to perform the feature you requested, by third-party service providers used to operate that feature. This Policy is intentionally careful and does not make blanket claims such as “never used for training,” “zero retention,” or “immediate deletion” for every third-party provider unless and until those points have been confirmed contractually and technically for the specific integration concerned.

1. Data controller

The data controller for the processing described in this Privacy Policy is:

DATASQUEEZE
SASU, société par actions simplifiée unipersonnelle — 994 883 916
50 AVENUE DES CHAMPS ELYSEES, 75008 PARIS
Privacy contact: contact@editmypdf.ai
Data Protection Officer: David Krief — dpo@editmypdf.ai

In this Privacy Policy, “EditMyPDF,” “we,” “us,” and “our” refer to the entity identified above.

This Privacy Policy describes EditMyPDF’s own processing as operator of the website and service. If a separate contract, data processing agreement, or enterprise agreement applies to a specific customer relationship, that document may supplement or override parts of this Policy for the processing it covers.

2. What data we process

2.1 Account and authentication data

When you create an account, sign in, maintain an authenticated session, or use account-linked features, we may process:

your email address;
your account identifier;
session and authentication events, including sign-in and sign-out;
session-related technical identifiers;
minimal profile information returned by the identity provider, where applicable;
information needed to associate your account with access rights, plan status, or subscription status.

Authentication may be handled through Auth0. This Privacy Policy does not attempt to list the exact names of all third-party cookies or storage entries associated with Auth0, because those may vary depending on browser, session type, identity-provider flow, and configuration.

2.2 Documents and file data

We process the files and related content needed to perform the actions you request, including:

uploaded PDF files;
images and other files used in document workflows;
conversion source files such as Word, Excel, PowerPoint, HTML, image, and similar formats;
files imported from Google Drive or Dropbox when you explicitly choose that feature;
file and workflow metadata needed to perform the requested processing, such as file type, format, size, page count, MIME type, and processing identifiers;
generated artifacts and outputs, including exported PDFs, generated DOCX/XLSX files, OCR results, extracted text, and final downloadable outputs.

2.3 User content

We also process the content you provide or generate within the service, including:

prompts, instructions, messages, and text entered by you;
annotations, edits, form-like content, or transformation instructions;
workflow, route, or pipeline configuration metadata;
intermediate processing context where needed to execute the requested task;
generated outputs returned by the service.

2.4 Technical and usage data

To operate the service, diagnose issues, secure the platform, and maintain reliability, we may process:

IP address;
user agent, browser, device, and operating environment signals;
timestamps;
technical logs;
run, job, conversion, request, and session identifiers;
execution states, failure states, error messages, and diagnostics;
product, reliability, and performance metrics;
limited data necessary for support, observability, debugging, and infrastructure integrity.

2.5 Payment and subscription data

When you purchase a plan, start checkout, maintain a subscription, or access billing features, we may process:

plan name and subscription status;
subscription lifecycle information, such as activation, renewal, expiration, cancellation, or reactivation;
customer, checkout-session, subscription, invoice, product, price, or billing identifiers;
limited payment history and billing records needed for subscription management, finance, support, failed-payment handling, and accounting;
information needed to activate, restrict, suspend, resume, or verify paid access, such as the current billing period end, paid-access expiry, or whether cancellation takes effect at period end;
limited checkout risk or attribution fields, where relevant to fraud control, abuse prevention, billing continuity, or conversion attribution.

Payments and subscriptions are handled through Stripe. Where payment is processed through Stripe-hosted or Stripe-controlled flows, EditMyPDF does not intend to store full card numbers or card security codes in its own systems. We may, however, receive and retain limited payment and billing metadata strictly necessary to manage subscriptions, reconcile billing, respond to support requests, and comply with our legal obligations. In the current implementation, this typically means limited Stripe-side identifiers and billing state, not the full Stripe object payload, and our local billing tables do not store raw Stripe webhook payloads.

2.6 Security, anti-fraud, and anti-abuse data

To protect the platform, enforce usage limits, and reduce fraud and abuse, including in trial or no-account scenarios, we may process:

session cookies, trial tokens, and other technical identifiers;
integrity and security signals linked to requests or sessions;
access and security logs;
anti-abuse and anti-fraud indicators;
device intelligence and related signals, including through Fingerprint Pro;
information used to apply trial limits, usage caps, rate limits, and related protections.

These processing activities are used to help detect account abuse, misuse of trial access, evasion of technical limits, unauthorized access, and attacks against the service.

2.7 Consent, preferences, and local state

We also process your preferences and related local state in order to respect your choices and provide a consistent experience, including:

cookie and tracking consent preferences;
language preference;
theme and interface preferences;
local state used to resume a flow, restore a draft, preserve an authentication intent, or resume checkout;
certain local attribution values where advertising consent has been given;
temporary workflow preferences, draft state, or route configuration where those features exist.

3. How we use the data

We use the categories of data described above for the following purposes:

To provide the core service, including PDF editing, conversion, OCR, AI-assisted document workflows, annotation, splitting, metadata editing, output generation, and download delivery.
To enable cloud import/export when you explicitly choose Google Drive, Dropbox, or similar integrations.
To manage accounts, authentication, sessions, and access control, including continuity between free, guest, and paid usage.
To manage subscriptions, payments, billing, renewals, cancellations, payment failures, and the billing portal.
To secure the platform, prevent fraud, detect and limit abuse, enforce trial limits, and protect the integrity of the service and its users.
To provide support and operate the service reliably, including debugging, diagnostics, observability, incident handling, and infrastructure monitoring.
To measure product usage and performance, only where permitted under the applicable consent framework.
To measure marketing campaigns and conversions, only where permitted under the applicable consent framework.
To comply with legal obligations, including tax, accounting, financial reporting, lawful disclosure, recordkeeping, and the protection or defense of legal claims.

Where necessary to investigate abuse, resolve incidents, or provide support, authorized personnel may access relevant logs, prompts, file-processing context, or outputs on a need-to-know basis.

4. Legal bases

Depending on the processing activity, EditMyPDF relies on the following legal bases under applicable data protection law, including the GDPR where applicable.

4.1 Performance of a contract or steps taken at your request before entering into a contract

We rely on this basis in particular for:

providing the service you requested;
executing conversions, OCR, editing actions, document transformations, exports, and downloads;
maintaining user sessions and authenticated access;
enabling cloud import or export when you request it;
connecting account status and access rights to a subscription;
enabling pre-subscription or trial workflows that you initiate.

4.2 Legal obligation

We rely on this basis in particular for:

issuing and retaining invoices;
bookkeeping and accounting;
tax compliance;
responding to valid legal requests from competent authorities;
meeting regulatory or statutory recordkeeping obligations.

4.3 Legitimate interests

We rely on legitimate interests where appropriate and proportionate, in particular for:

platform security;
fraud prevention, abuse prevention, and misuse detection;
trial limitation and anti-circumvention measures;
technical logs, monitoring, service reliability, and incident response;
troubleshooting, debugging, and support operations;
defending our rights, preserving evidence, and managing billing disputes where they arise.

Where support or diagnostic activity is directly tied to a service operation you requested, part of the associated processing may also fall under performance of a contract.

4.4 Consent

We rely on consent where the law requires it, including for:

optional analytics technologies;
advertising and marketing technologies;
optional cookies, pixels, and similar trackers;
browser-side and server-side conversion measurement where consent is required for that use.

We do not rely on legitimate interests as a substitute where applicable law requires consent. You may withdraw consent at any time, without affecting the lawfulness of processing carried out before withdrawal.

5. Cookies, local storage, and similar technologies

EditMyPDF uses cookies, local storage, session storage, and similar technologies to operate the service, remember user choices, maintain security, resume workflows, and, where permitted, perform analytics or advertising measurement.

5.1 Strictly necessary technologies

Some technologies are strictly necessary and remain active because they support essential product and security functions such as:

maintaining sessions;
protecting forms and requests;
securing settings and operational flows;
remembering essential preferences;
preserving state across certain upload, document, or checkout flows;
limiting abuse or repeat trial misuse.

5.2 Examples of first-party storage used by EditMyPDF

Depending on the feature used, EditMyPDF may use first-party storage such as:

language storage entries, for example editmypdf_lang and editmypdf:lang;
trial or anti-abuse storage entries, for example trial_token and editmypdf:trial-started;
settings session and CSRF-related entries, for example settings_session and settings_csrf;
theme and interface preferences, for example editmypdf:theme;
authentication intent and billing-resume state, for example editmypdf:auth-intent and editmypdf:billing-checkout-resume;
local attribution values, such as editmypdf:tiktok-ttclid, only where the required advertising consent has been obtained;
temporary drafts, workflow preferences, or pipeline configuration state.

The exact names, lifetimes, and implementation details of these technologies may evolve over time. Our /cookies page is intended to provide the more operationally detailed view.

5.3 Consent preferences

We retain a compact record of your consent preferences so that we can honor your choices and, where necessary, demonstrate that a preference was recorded. The consent preference storage remains valid for 180 days, unless you change your preferences sooner.

6. Analytics, advertising, and server-side conversion measurement

6.1 General rule

Strictly necessary technologies remain active because they are required for core functionality and security. Optional analytics and advertising technologies are intended to remain off by default unless and until the relevant consent is collected.

This includes security, fraud-prevention, abuse-prevention, trial-protection, and service-integrity controls such as device intelligence or fingerprint-based signals where EditMyPDF considers those controls necessary to protect the service.

6.2 Browser-side measurement

Browser-side measurement refers to tags, scripts, pixels, or similar tools that run in your browser or on your device and may read from or write to cookies or local storage.

Depending on your consent choices and the feature configuration in effect, EditMyPDF may use technologies from providers such as:

Google Tag Manager;
Google Analytics 4;
Microsoft Clarity;
Meta Pixel;
TikTok Pixel.

These tools may be used to understand site usage, measure product performance, evaluate campaign effectiveness, and attribute conversions, subject to the applicable consent rules.

In the current CMP / vendor registry, Google Analytics 4 and Microsoft Clarity are governed by the Analytics consent category, while Meta Pixel and TikTok Pixel are governed by the Advertising consent category.

6.3 Server-side measurement

EditMyPDF may also send certain conversion or measurement events from its own systems rather than only from your browser. This is generally referred to as server-side measurement and may include tools or interfaces such as:

GA4 Measurement Protocol;
Meta Conversions API;
TikTok Events API.

Server-side measurement can be used to improve reliability, de-duplicate browser and server events, attribute conversions, and measure product or commercial outcomes. It does not remove the need to respect consent rules. Where a server-side event is used for analytics or advertising purposes that require consent, that event should be governed by the same consent framework as the related browser-side measurement.

6.4 More detail

For the detailed operational view of categories, preference states, and providers, please see our /cookies page.

7. AI, document processing, and third-party model providers

When you use AI-assisted document features, OCR, extraction, transformation, rewriting, or similar content-processing features, EditMyPDF may process:

all or part of the document you provide;
text extracted from the document;
your prompts, instructions, and parameters;
intermediate processing data needed to execute the feature;
generated outputs returned to you.

At the date of this Policy, the third-party AI or document-processing provider families materially wired into the service code path are:

OpenAI, for document-intent parsing, planning, certain multimodal context steps, and some file-assisted document rewriting or PDF-processing routes;
Anthropic (Claude), for fallback or alternative planning, multimodal interpretation, and certain vision-based detection routes;
xAI, for certain image redraw or image-edit operations used to replace or regenerate a selected visual region;
Google Cloud Vision / OCR, for OCR enrichment and certain object or logo detection steps.

Depending on the feature and route used, the categories of data sent to these providers may include:

prompts, instructions, and user-entered requests;
extracted text, OCR text, selected snippets, or other focused document context;
rendered page images, previews, or PDF pages;
in some OpenAI file-assisted routes, a temporarily uploaded PDF or other file reference;
in some xAI redraw routes, a prompt together with a selected crop, mask, or reference image needed to edit the target region.

This Privacy Policy intentionally avoids making unsupported blanket statements such as “no provider ever retains data,” “no provider ever uses content for model improvement,” or “all content is immediately deleted everywhere.” Those points depend on the provider, the API and plan used, the contractual terms in force, and the actual technical configuration deployed by EditMyPDF. Where stronger confirmed safeguards apply, this Policy may be updated to reflect them.

For these business/API workflows, EditMyPDF currently treats OpenAI, Anthropic, xAI, and Google Cloud as processors or subprocessors acting on our instructions under their business/API terms and data-processing terms.

More specifically:

OpenAI: OpenAI’s Data Processing Addendum states that OpenAI acts as a data processor for Customer Data processed on behalf of the customer. OpenAI’s enterprise privacy commitments state that business data is not used to train models by default. However, OpenAI’s file API documentation states that, unless an explicit expiration policy is set, uploaded files other than purpose=batch persist until manually deleted. EditMyPDF therefore attempts best-effort deletion of OpenAI file uploads after the relevant run completes, but this Policy does not claim a single provider-side retention ceiling across every OpenAI API surface.
Anthropic: Anthropic’s Privacy Center states that, for commercial products, the customer is the controller and Anthropic acts as processor, and that commercial data is not used to train Anthropic’s models unless the customer opts into a specific program. Anthropic also states that Anthropic API inputs and outputs are deleted from its backend within 30 days by default, subject to documented exceptions or a separate zero-data-retention arrangement.
xAI: xAI’s Data Processing Addendum states that xAI is a processor for personal data processed on the customer’s behalf. xAI’s enterprise FAQ states that business inputs and outputs are not used to train its models by default and are automatically deleted within 30 days unless another written arrangement applies or retention is legally required, for example for flagged misuse or abuse.
Google Cloud Vision / OCR: Google Cloud’s data-processing terms state that Google is a processor for Customer Personal Data, and Google Cloud service terms state that Google will not use Customer Data to train or fine-tune AI/ML models without prior permission or instruction. In the current EditMyPDF implementation, Google Cloud Vision is used as a request/response OCR or vision service rather than as a long-lived end-user document repository. This Policy therefore distinguishes Google Cloud’s contractual role and our own retention periods, but does not claim a single fixed provider-side deletion period for every Google Cloud Vision log or backend trace.

Access to documents, prompts, outputs, and associated context within EditMyPDF should be limited to authorized personnel who need that access to provide the service, investigate abuse, resolve incidents, provide support, or comply with legal obligations.

If you upload documents containing personal data of third parties, confidential information, or sensitive data, you are responsible for ensuring that you have the right to provide that content and that doing so is necessary and lawful for your intended use of the service.

8. Sharing, recipients, and service providers

We do not disclose uploaded files to unrelated third parties for their own independent use. We share data only where necessary for the purposes described in this Privacy Policy, including with the following categories of recipients:

AWS, for hosting, application infrastructure, storage, and related operational services;
Auth0, for authentication, identity, and session management;
Stripe, for payment processing, checkout, subscription management, customer billing, and invoicing;
OpenAI, for planning, rewriting, multimodal context, and certain file-assisted document-processing routes;
Anthropic, for fallback or alternative planning, multimodal interpretation, and certain vision-based detection routes;
xAI, for certain image redraw or image-edit routes;
Google Cloud, for OCR enrichment and certain object or logo detection routes;
Fingerprint Pro, for device intelligence, fraud prevention, trial limitation, and anti-abuse measures;
Google, including Google Analytics and related measurement tools, where those tools are enabled in accordance with your consent choices;
Microsoft, including Microsoft Clarity, where those tools are enabled in accordance with your consent choices;
Meta, where analytics, attribution, or advertising tools from Meta are enabled in accordance with your consent choices;
TikTok, where analytics, attribution, or advertising tools from TikTok are enabled in accordance with your consent choices;
Google Drive and Dropbox, where you explicitly choose those integrations for file import or export;
professional advisers, auditors, insurers, and competent authorities, where necessary and lawful.

For the document-processing API flows listed above, these providers are intended to act under their business terms and data-processing terms as processors or subprocessors on our instructions. By contrast, analytics, attribution, advertising, identity, payment, and cloud-import/export providers may act under roles that vary depending on the service used and the processing context. Where required, we seek to put appropriate contractual safeguards in place.

For the current Google Drive browser integration, EditMyPDF uses Google Identity Services and Google Picker in a user-initiated popup flow and currently requests the single OAuth scope https://www.googleapis.com/auth/drive.file for both import and export. In the current implementation, EditMyPDF does not request or store a Google Drive refresh token. The Google Drive access token obtained in the browser is kept only in transient browser memory for the current page runtime, is reused only until its provider-reported expiry (with a short safety buffer), and is not intentionally persisted by EditMyPDF in its own cookies, localStorage, or sessionStorage.

8.1 Recipient and subprocessor matrix

The table below is the current high-level matrix we are prepared to publish for the main recipient families used by EditMyPDF.

Provider / service family	Main use in EditMyPDF	Main categories of data involved	Public role assumption
AWS	Application hosting, storage, queues, logs, and infrastructure operations	account data, run metadata, uploaded files, outputs, technical logs, billing metadata	Processor / subprocessor for the hosting and infrastructure services we operate on our own account
Auth0	Authentication, session continuity, identity, and sign-in protection	account identifiers, session/authentication data, minimal profile claims	In practice, this may involve roles that vary by service context; for the identity service we integrate into EditMyPDF, we publicly treat Auth0 as an identity service provider acting under its contractual terms, not as an unrelated recipient of your data for our product features
Stripe	Checkout, subscription lifecycle, billing portal, invoicing, and payment-related status	customer, checkout-session, subscription, invoice, product and price identifiers; billing status; limited risk/attribution fields	In practice, Stripe’s role may vary depending on the payment and regulatory context. We therefore do not claim a single processor-only role for every Stripe-related processing context
OpenAI	Planning, rewriting, multimodal context, and certain file-assisted document-processing routes	prompts, extracted text, OCR snippets, page images, certain temporary file references	Processor / subprocessor for the document-processing API routes we trigger on your behalf
Anthropic	Fallback or alternative planning, multimodal interpretation, and certain detection routes	prompts, extracted text, OCR snippets, page images, focused document context	Processor / subprocessor for the document-processing API routes we trigger on your behalf
xAI	Certain image redraw and image-edit routes	prompts, selected crops, masks, reference images, focused visual context	Processor / subprocessor for the document-processing API routes we trigger on your behalf
Google Cloud Vision / OCR	OCR enrichment and certain object/logo detection routes, where enabled	rendered page images, OCR/vision request payloads, focused document visuals	Processor / subprocessor for the OCR/vision request-response routes we trigger on your behalf, where that route is enabled
Fingerprint Pro	Device intelligence, trial protection, anti-abuse, and fraud prevention	device/browser/network signals, visitor or request identifiers, related technical enforcement metadata	Processor / subprocessor for anti-abuse and fraud-prevention services operating on our instructions under the applicable business terms
Google Analytics / Google Tag Manager	Consent-gated browser-side and server-side analytics measurement	analytics events, browser identifiers, certain attribution or conversion metadata where relevant	Role may vary depending on the tool, configuration, and provider terms. We therefore describe Google here as an analytics/measurement recipient whose role may vary by context
Microsoft Clarity	Consent-gated behavioral analytics and session insights	behavioral analytics events, browser/session interaction signals, related measurement metadata	Role may vary depending on the tool and provider terms. We therefore describe Microsoft Clarity here as an analytics recipient whose role may vary by context
Meta	Consent-gated advertising attribution, conversion measurement, and related marketing tools	conversion events, advertising identifiers, browser/server-side attribution metadata	Role may vary depending on the tool and provider terms. We therefore describe Meta here as an advertising/measurement recipient whose role may vary by context
TikTok	Consent-gated advertising attribution, conversion measurement, and related marketing tools	conversion events, advertising identifiers, click IDs, browser/server-side attribution metadata	Role may vary depending on the tool and provider terms. We therefore describe TikTok here as an advertising/measurement recipient whose role may vary by context
Google Drive / Dropbox	User-requested cloud import and export	selected file metadata, OAuth/session context, imported or exported files that you choose to transfer; for Google Drive, a short-lived browser access token used for the current user-initiated transfer flow	Role may vary depending on the service and the exact import/export flow. We therefore describe these services as cloud file-transfer recipients whose role may vary by context
Professional advisers, auditors, insurers, and competent authorities	Legal compliance, defense of rights, audits, insurance, and lawful disclosure	data relevant to the concrete matter concerned	Role depends on the concrete legal or professional context and is not uniform across every scenario

This matrix is a practical transparency tool, not a substitute for the provider’s own legal documentation or for the contractual terms that apply to a specific service context. We may refine it when a provider’s role becomes more narrowly defined in the deployed service.

8.2 Internal access, support, and incident handling

Within EditMyPDF, access to retained account, billing, run, and document-related data is intended to be limited to authorized personnel on a need-to-know basis.

In the current product implementation, the main internal support and incident-handling surface is a dedicated internal admin / settings access plane protected by separate internal authentication controls. It is not a general public user area and is distinct from ordinary end-user account access.

Some internal observability and incident-handling views are intentionally designed to expose only reduced information such as identifiers, timestamps, statuses, rejection reasons, route information, limited prompt excerpts, and other operational metadata rather than the full underlying document content.

Where this is necessary to investigate abuse, analyze a concrete incident, diagnose a failed run, respond to a support request, or comply with a legal obligation, authorized internal personnel using that internal admin/settings access may also access run-level artifacts that are still within their retention window. Depending on the case, this can include retained result files, user-visible manifests, admin/debug manifests, or debug bundles and related diagnostics generated for internal troubleshooting surfaces.

We do not intend routine support operations to become a parallel long-term archive of your documents or prompts. Internal access remains constrained by the same retention windows described in this Policy: once the relevant run content, debug artifacts, or related records are deleted or anonymized from active systems, they are no longer intended to remain available through those active internal tools, except for limited backup, legal-archive, or evidentiary situations described elsewhere in this Policy.

9. International transfers

Some providers used by EditMyPDF may process personal data outside your country of residence or outside the European Economic Area, the United Kingdom, or Switzerland.

Where required by law, we seek to ensure that such transfers are subject to an appropriate transfer mechanism, such as:

an adequacy decision;
standard contractual clauses;
or another legally recognized safeguard.

As of the date of this Policy, the current provider-by-provider assumptions we are prepared to make publicly are:

Provider	Current region or endpoint assumption	Transfer mechanism we currently rely on publicly
AWS	Our primary application hosting and storage are currently deployed in AWS Paris (`eu-west-3`).	Where access or onward transfers outside the EEA/UK/Switzerland are involved, we rely on the AWS GDPR Data Processing Addendum, including the applicable standard contractual clauses or another lawful mechanism recognized under that framework.
Auth0	Our current tenant is configured on a `dev-nyv3j6xgknngsdf8.us.auth0.com` tenant, so account, authentication, and session data may be processed in the United States.	We rely on the Okta/Auth0 data processing terms, including the applicable EU SCCs and UK Addendum where required, or another lawful transfer mechanism offered under those terms.
Stripe	Our current service configuration does not publish a dedicated EEA-only Stripe processing endpoint. Payment and billing data may therefore be processed in the EEA, the United States, or other Stripe locations used by Stripe and its affiliates.	We rely on Stripe’s data processing terms, including the applicable EU SCCs, UK Addendum, adequacy decision, or another lawful transfer mechanism made available by Stripe.
OpenAI	Our current service configuration uses OpenAI’s general business/API endpoints rather than a dedicated EEA-only regional endpoint. Data sent to OpenAI may therefore be processed outside the EEA/UK/Switzerland, including in the United States.	We rely on the OpenAI Data Processing Addendum and the transfer safeguards it provides, including the applicable standard contractual clauses, adequacy decision, or another lawful mechanism recognized under that framework.
Anthropic	Our current service configuration does not expose a dedicated EEA-only Anthropic endpoint. Data sent to Anthropic may therefore be processed in the United States or other jurisdictions used by Anthropic and its subprocessors.	We rely on Anthropic’s business/API terms and data-processing commitments, including the applicable SCC-based safeguards or another lawful transfer mechanism offered under those terms.
xAI	Our current service configuration does not expose a dedicated EEA-only xAI endpoint. Data sent to xAI may therefore be processed in the United States or other jurisdictions used by xAI and its subprocessors.	We rely on the xAI Data Processing Addendum, including the applicable EU SCCs, UK Addendum, or another lawful transfer mechanism made available under xAI’s business terms.
Google Cloud Vision / OCR	Where this route is enabled, Google Cloud Vision / OCR is used as a request/response service. In the current service configuration, we do not publish a dedicated EEA-only Google Cloud Vision endpoint commitment.	We rely on the Google Cloud data-processing terms, including the applicable standard contractual clauses, adequacy decision, or another lawful transfer mechanism offered under Google Cloud’s terms.
Fingerprint Pro	Our current server-side verification configuration points to Fingerprint’s EU API base (`https://https://eu.api.fpjs.io`), but provider or subprocessor access may still involve other jurisdictions.	We rely on Fingerprint’s business/data-processing terms, including the applicable standard contractual clauses or another lawful transfer mechanism offered under those terms.

For browser-side analytics, advertising, and import/export providers such as Google Analytics, Google Drive, Meta, TikTok, Microsoft Clarity, and Dropbox, the exact processing locations may vary depending on the feature, consent state, browser flow, and provider infrastructure used at the time. Where those services transfer personal data outside the EEA/UK/Switzerland, we intend to rely on the provider’s adequacy arrangement, standard contractual clauses, or another lawful transfer mechanism made available under the provider’s terms.

This section reflects our current runtime and contractual assumptions as of the date above. We may update it if a provider is moved to a dedicated EU regional offering, if our deployment region changes, or if a provider changes the lawful transfer mechanism it makes available to us.

10. Retention

We keep personal data only for as long as necessary for the relevant purpose, after which we delete it, anonymize it, or retain it only where a lawful retention obligation or legitimate evidentiary need applies.

10.1 Account and authentication data

Account and authentication data are retained for as long as the account remains active.

If an account is explicitly closed, or if it becomes inactive for 24 months without meaningful login or service activity and without an active paid entitlement, the operational account data is scheduled for deletion or irreversible anonymization within 30 days.

If you submit an explicit account-deletion request, the account enters a restricted state immediately and the same operational deletion or anonymization path is scheduled after a 30-day cancellation window, unless you cancel the request in time.

During that restricted window, ordinary authenticated product usage is blocked. In the current implementation, the remaining self-service actions are limited to checking the deletion status, cancelling the pending deletion request in time, and requesting, following, or downloading a personal-data export that is still available.

Signing in again does not by itself reopen the account or cancel the pending deletion request. Cancellation must be explicit before the deadline.

Minimal legal, billing, or security archive records may remain beyond that operational window where required by law or where necessary to preserve evidence.

10.2 Temporary uploads before submission

Validated staging uploads, pre-submission files, and similar temporary buffers are retained for 30 minutes after the last real activity on that item, not simply 30 minutes after creation.

“Last real activity” includes, where relevant, opening the item, previewing it, releasing it, consuming it into a run, or performing a pre-submit transformation that keeps it alive.

If a residual object-storage copy still exists after that operational expiry, our cleanup process is designed to hard-delete it no later than 24 hours after the expiry time.

10.3 Submitted run content, prompts, outputs, and processing artifacts

For submitted runs, we retain the run content for 72 hours after the run reaches a terminal state. This includes, as applicable:

uploaded source files;
prompts and instructions;
extracted text and user-visible OCR outputs;
generated outputs and downloadable artifacts;
editor assets, intermediate processing artifacts, and run-linked snapshots that still contain or reflect document content.

A terminal state includes success, failure, cancellation, or automatic abandonment of a run that stopped progressing. If a run becomes stuck, it may be automatically abandoned after 24 hours without worker heartbeat or progress, or after 7 days of absolute age, after which the same 72-hour content-retention window applies.

If residual object-storage artifacts remain after the main content window, our cleanup process is designed to hard-delete them no later than 24 hours after the content expiry time.

For user runs, we do not retain detailed internal OCR payloads such as per-page OCR text, OCR word lists, bounding boxes, OCR snippets, or internal OCR-to-LLM snapshots as a durable record. If a run is executed in an internal admin/test debug mode, those detailed OCR debug payloads are stored separately and are purged after 30 days, with a hard-delete grace period of up to 24 hours.

10.4 Minimal run metadata

After the content window closes, we may keep a reduced operational record for up to 180 days. This minimal metadata may include items such as:

run identifiers;
a short normalized prompt excerpt, clipped to about 500 characters, where needed for operational support, search, or debugging without keeping the full prompt body;
timestamps and status transitions;
file size, page count, preset, and routing information;
synthetic error information;
synthetic cost or usage information that does not contain the document content itself.

The purpose of this shorter metadata record is reliability, abuse prevention, finance reconciliation, and operational debugging without keeping the underlying document content.

10.5 Payment, billing, and subscription data

Payment, billing, and subscription-related data follow several distinct retention windows:

we locally store limited Stripe-related metadata such as customer, checkout-session, subscription, invoice, product, and price identifiers; subscription status; current billing period end; paid-access expiry; and certain limited checkout risk or attribution fields;
we do not locally store full card numbers or card security codes, and our local billing tables do not store raw Stripe webhook payloads;
in the current implementation, the main Stripe lifecycle events persisted or archived locally are the checkout completion state, subscription snapshots, subscription deletion state, paid invoices, failed invoice payments, limited checkout-session state, and payload-free webhook idempotency markers;
accounting and restricted billing archive records are assigned a 10-year retention period where required for bookkeeping, invoicing, tax, and finance obligations;
opened, failed, or expired checkout-session records are retained for up to 90 days;
checkout fields used for marketing attribution are retained for up to 90 days;
checkout fields used for risk or fraud analysis are retained for up to 180 days;
completed checkout-session records may remain longer in operational billing/account records, but their marketing attribution fields are scrubbed after the 90-day window and their risk/fraud fields are scrubbed after the 180-day window;
payload-free Stripe webhook idempotency markers are retained for up to 365 days to prevent duplicate processing.

At the date of this Policy, EditMyPDF does not operate a dedicated local chargeback or charge.dispute.* evidence archive as a standard product flow, and our local billing tables do not currently persist raw Stripe dispute payloads by default.

If a concrete payment dispute, chargeback, refund investigation, or legal defense requires local preservation, we may retain only the minimum billing, account, support, and evidentiary records strictly necessary for that dispute, for the legally relevant period. In payment-card contexts, that period is typically 13 months from the debit date, or 15 months for deferred debit where that longer period applies.

10.6 Technical logs, security, anti-abuse, and observability data

We apply separate retention windows to different technical and security records:

application and observability logs are kept for up to 30 days in production;
security and authentication audit events are retained for up to 365 days;
anti-abuse records, device-intelligence signals, fingerprint-related controls, and similar technical enforcement metadata are retained for up to 180 days.

Within that broader anti-abuse category, some controls are intentionally much shorter-lived. In the current service configuration, this includes, for example, a trial cookie of about 1 day, certain Fingerprint event-freshness and replay windows of about 15 minutes (roughly 15 minutes 30 seconds for replay protection), short burst or concurrency windows measured in seconds or minutes, certain delay windows of about 10 minutes, and certain block or exhaustion windows of up to 24 hours. Certain graph or linkage relations used to detect coordinated abuse may remain active for up to 7 days before aging out.

Run IDs and related request or job IDs can therefore appear on different retention surfaces: in minimal run metadata for up to 180 days, in application or observability logs for up to 30 days, and in restricted security or audit records for up to 365 days where incident handling or evidence preservation requires it.

These records are intended to support security, abuse prevention, support, and service reliability, and are designed not to serve as a long-term archive of document content, prompts, OCR text, extracted text, or internal OCR debug payloads.

10.7 Terms, service consent, and legal proof

Records used to prove acceptance of our Terms, service-side consent decisions, or similar legal proof events are retained in a restricted archive for 5 years by default.

Where a legally qualifying consumer electronic-contract archiving obligation applies, the relevant proof record may instead be retained for 10 years.

We try to keep only the minimum proof data needed for that purpose rather than a full profile archive. This section does not cover cookie-consent preference storage, which is described on the /cookies page.

10.8 Analytics, advertising, and attribution data

If you consent to analytics or advertising, the related browser-side technologies follow the lifetimes described on the /cookies page.

Where EditMyPDF keeps its own first-party marketing attribution or conversion records, those records are retained for up to 90 days.

10.9 Saved signatures

Guest signatures are retained in active systems for 30 days. If object deletion must be retried, our cleanup process is designed to enforce final removal no later than 24 hours after that expiry window.

Account-linked signatures are retained for as long as the account remains active and are then deleted within 30 days after account closure or closure for inactivity.

10.10 Preferences and first-party browser storage

As an operational indication for browser-side storage controlled by EditMyPDF:

editmypdf_lang is stored for 365 days;
trial_token is stored for about 1 day;
settings_session and settings_csrf are stored for about 30 minutes;
editmypdf:auth-intent and editmypdf:billing-checkout-resume are stored for up to 30 minutes or until the tab or session ends;
editmypdf:tiktok-ttclid, where used after Advertising consent, is stored for up to 30 days and is cleared if Advertising consent is not granted or is later withdrawn;
language, theme, draft, and similar local preference entries may remain until you change them, clear your browser storage, or your browser removes them according to its own lifecycle.

For the current Google Drive integration, EditMyPDF does not intentionally persist the Google Drive OAuth access token in its own cookies, localStorage, or sessionStorage, and does not request or store a refresh token. The current browser-side implementation keeps the access token only in transient memory for the current page runtime, reuses it only for the current scope while it remains valid, and discards it when it expires or when the page runtime is reset. Google or the browser may separately maintain their own session state on Google-controlled domains.

10.11 Backups

When data is deleted from live systems, it may remain for a limited period in encrypted backups and disaster-recovery media before those backups age out through their normal rotation and restoration lifecycle.

11. Security

EditMyPDF implements technical and organizational measures appropriate to the nature of the data processed and the risks involved. Depending on the context, this may include access controls, session controls, request protection, logging, monitoring, abuse prevention, rate-limiting, provider management, and infrastructure safeguards.

No system is completely risk-free. For that reason, we encourage users to upload only the data needed for the intended task and to avoid submitting unnecessary sensitive information where it is not required.

12. Your rights

Subject to the conditions and limitations provided by applicable law, you may have the right to:

access your personal data;
rectify inaccurate personal data;
request erasure of personal data;
object to certain processing;
request restriction of processing;
receive a portable copy of data, where applicable;
withdraw consent at any time where processing is based on consent;
lodge a complaint with a competent supervisory authority.

To exercise your rights, you may contact us at contact@editmypdf.ai or using the contact details listed in the “Data controller” section. To protect your data, we may request reasonable information to verify your identity before responding to the request.

For logged-in accounts, the current product also provides a self-service workflow for certain rights in the account settings area:

you may request a portable ZIP export of the data still retained for your account;
these exports are generated asynchronously, are generally limited to one new request per 24 hours, and remain downloadable for up to 7 days once completed;
you may submit an account-deletion request directly from the account settings area, which immediately places the account in the restricted state described above and starts the 30-day cancellation window;
re-authenticating does not by itself cancel a pending deletion request; cancellation must be explicit before the deadline.

These self-service tools do not override the limited archives or legal retention windows described elsewhere in this Policy.

You can also manage your cookie and tracking preferences through our /cookies page or the consent management link made available on the site.

If you believe that your personal data has been processed in a way that does not comply with applicable law, you may file a complaint with the supervisory authority in your place of residence, place of work, or the place of the alleged infringement, including the CNIL where applicable.

13. Contact

For questions about privacy, your data, this Policy, or an individual rights request, please contact:

contact@editmypdf.ai<br> 50 AVENUE DES CHAMPS ELYSEES, 75008 PARIS

Where relevant, you may include helpful context such as the email address used for the account, the approximate date of use, or a run / job identifier if available.

14. Changes to this Privacy Policy

We may update this Privacy Policy to reflect changes to the service, its features, its providers, or our legal obligations. The “Last updated” date at the top of this page indicates the version currently in force.