Privacy Policy

Last updated: August 26, 2026

This policy describes how OpenOCR handles account data, submitted documents, request records, and OCR results. OpenOCR does not make a platform-wide zero-data-retention promise: both OpenOCR's storage and the selected provider's handling apply to a request.

1. Account and payment data

When you create and fund an OpenOCR account, we handle:

Account information: Your email address and authentication records, managed through Supabase Auth.
API credentials: API key records are used to authenticate requests. OCR request rows reference the key record used for a request.
Payment information: Stripe processes card payments. OpenOCR stores transaction and credit-ledger records, but not complete card details.

2. How document processing works

The OCR API accepts a base64-encoded file or a document URL. OpenOCR routes the input to the engine you select. Depending on the engine and file type, OpenOCR may first convert a PDF into page images. The document, its URL, or those derived page images are then passed to the selected engine's provider so it can perform OCR. A provider may be an OpenOCR-operated service or an external cloud service.

External providers receive the content needed to process the request. Their handling of that content is governed by their own privacy policy, terms, and any agreement you have with them. Provider-side logging, retention, training, and data-region practices vary; OpenOCR does not control them.

3. What OpenOCR stores for OCR requests

The current application database stores the following:

Request metadata: Request and idempotency identifiers, the selected engine and provider, status, input type, page count, price and cost fields, latency, provider model and token counts when available, errors, request options, source tag, and timestamps.
Input reference: For URL input, the full submitted URL is stored with the request. For base64 input, the request row stores the markerinline_base64, not the base64 document bytes themselves. The bytes still pass through OpenOCR's services and the selected engine during processing. See “Failed-request diagnostics” below for the one case in which a copy of the submitted file is kept.
OCR results: When OpenOCR creates a persisted request record, a successful outcome stores the full extracted text and a shorter preview (currently up to 2,000 characters) in that record.
Failed-request diagnostics: When an OCR request fails, OpenOCR stores a copy of the submitted file in private object storage so the failure can be diagnosed. This applies only to failed requests; a request that succeeds does not have its file stored this way. The copy is keyed by request ID and is retained as described under Retention below.
Usage aggregates: Daily usage records store the account, date, engine, page count, and cost used for dashboard reporting, billing, and analytics. These rows do not contain the source document.
Large-PDF job data: Large asynchronous PDF jobs also store progress, per-page extracted text, the final result, and errors in a job record while polling is available. The completed text is also copied to the OCR request record.

4. Retention

OCR requests, results, and usage aggregates: The current application does not set an automatic expiration period for these records. Request metadata, stored document URLs, and extracted text therefore remain stored unless the records are deleted. You should not assume that they are purged after 24 hours or another fixed interval.
Failed-request diagnostic copies: Copies of files from failed requests expire automatically 7 days after they are stored, enforced by an object-storage lifecycle rule rather than by application code. Contact support if you would prefer that OpenOCR not retain these copies for your account.
Large-PDF job records: Once a job succeeds or fails, it is eligible for deletion one hour after the job was created, with cleanup checked every 15 minutes. Active jobs are retained until they reach a terminal state. This job cleanup does not delete the extracted text copied to the OCR request record.
Account relationship: OCR request and usage rows are linked to the authentication account with cascading database relationships. This is not a routine retention schedule; contact support to request account or data deletion.

5. Other service providers

Services used by the current application include:

Supabase: Authentication and database hosting.
Stripe: Payment processing.
Cloudflare: Public traffic routing and optional Turnstile bot protection on authentication forms.
Microsoft Graph: Email delivery. When email is enabled, the recipient address and message content are sent through Microsoft's service.
Google Analytics: The Google tag loads on production pages for site analytics.
OCR providers: The selected provider receives document content as described above. Review that provider's current policy before sending sensitive content.

6. How we use stored data

Provide OCR results, request status, asynchronous polling, and idempotent retries.
Calculate charges, maintain credit records, and show account usage.
Diagnose errors, monitor engine health, and improve service reliability.
Send service, security, billing, and account communications.

7. Security

The public website and API use HTTPS. Database row-level policies restrict customers to reading their own request and usage records. Operational service credentials can access these records to run and support the service. No security control eliminates all risk.

8. Your choices

To ask about access to, correction of, or deletion of your account data, use the private support channels on our contact page. The current database treats credit-ledger entries as append-only billing records, so they are handled separately from OCR request and usage rows.

9. Changes to this policy

We may update this policy when the service or its data practices change. The date at the top identifies the latest revision.

1. Account and payment data

When you create and fund an OpenOCR account, we handle:

Account information: Your email address and authentication records, managed through Supabase Auth.

API credentials: API key records are used to authenticate requests. OCR request rows reference the key record used for a request.

Payment information: Stripe processes card payments. OpenOCR stores transaction and credit-ledger records, but not complete card details.

2. How document processing works

3. What OpenOCR stores for OCR requests

The current application database stores the following:

Request metadata: Request and idempotency identifiers, the selected engine and provider, status, input type, page count, price and cost fields, latency, provider model and token counts when available, errors, request options, source tag, and timestamps.

Input reference: For URL input, the full submitted URL is stored with the request. For base64 input, the request row stores the markerinline_base64, not the base64 document bytes themselves. The bytes still pass through OpenOCR's services and the selected engine during processing. See “Failed-request diagnostics” below for the one case in which a copy of the submitted file is kept.

OCR results: When OpenOCR creates a persisted request record, a successful outcome stores the full extracted text and a shorter preview (currently up to 2,000 characters) in that record.

Failed-request diagnostics: When an OCR request fails, OpenOCR stores a copy of the submitted file in private object storage so the failure can be diagnosed. This applies only to failed requests; a request that succeeds does not have its file stored this way. The copy is keyed by request ID and is retained as described under Retention below.

Usage aggregates: Daily usage records store the account, date, engine, page count, and cost used for dashboard reporting, billing, and analytics. These rows do not contain the source document.

Large-PDF job data: Large asynchronous PDF jobs also store progress, per-page extracted text, the final result, and errors in a job record while polling is available. The completed text is also copied to the OCR request record.

4. Retention

OCR requests, results, and usage aggregates: The current application does not set an automatic expiration period for these records. Request metadata, stored document URLs, and extracted text therefore remain stored unless the records are deleted. You should not assume that they are purged after 24 hours or another fixed interval.

Failed-request diagnostic copies: Copies of files from failed requests expire automatically 7 days after they are stored, enforced by an object-storage lifecycle rule rather than by application code. Contact support if you would prefer that OpenOCR not retain these copies for your account.

Large-PDF job records: Once a job succeeds or fails, it is eligible for deletion one hour after the job was created, with cleanup checked every 15 minutes. Active jobs are retained until they reach a terminal state. This job cleanup does not delete the extracted text copied to the OCR request record.

Account relationship: OCR request and usage rows are linked to the authentication account with cascading database relationships. This is not a routine retention schedule; contact support to request account or data deletion.

5. Other service providers

Services used by the current application include:

Supabase: Authentication and database hosting.

Stripe: Payment processing.

Cloudflare: Public traffic routing and optional Turnstile bot protection on authentication forms.

Microsoft Graph: Email delivery. When email is enabled, the recipient address and message content are sent through Microsoft's service.

Google Analytics: The Google tag loads on production pages for site analytics.

OCR providers: The selected provider receives document content as described above. Review that provider's current policy before sending sensitive content.