Security designed around untrusted PDFs.

Processing architecture

The current processing class is local. Supported analysis, cleanup, OCR and optimization run in the browser; there is no active document-processing API or server worker receiving uploaded PDFs in the current product.

Because server-assisted document processing is not enabled, server file isolation, temporary object storage, deletion jobs and processing-rate limits are not active paths today. They become required before any future server-processing feature is enabled.

Input safeguards

• • PDF-only file selection plus a PDF header check before full analysis.
• • Current file-size limit: 25 MB.
• • Current page-count limit: 25 pages.
• • Unusually large page dimensions are rejected above 7,200 PDF points.
• • Password-protected/encrypted PDFs are rejected in V1 rather than prompting for or storing a password.
• • Malformed, unreadable, memory-exhausting and validation-timeout cases are mapped to controlled user-facing errors instead of raw stack traces.

Browser and transformation safeguards

• • Low-resolution analysis is separated from heavier visual cleanup work.
• • Rendering and compression paths use bounded render dimensions instead of blindly rasterizing at arbitrary page size.
• • Local OCR is capped at 10 scanned target pages based on measured browser-performance testing.
• • Pages with annotations are skipped by destructive visual replacement instead of silently flattening interactive content.
• • Canvases and PDF worker/task resources are released when work completes or is cancelled where supported.

Output validation

Before the download is presented as successful, PDFBright reopens the generated PDF and checks that it is a valid PDF, that the expected page count survived, that native text was not unexpectedly lost, that OCR text remains searchable on OCR pages, and that visual pages still contain drawing operations. A failed validation does not become a success screen.

Web-app hardening

The deployed site uses HTTPS through its hosting platform. PDFBright also sends browser security headers that disable framing, prevent MIME sniffing, restrict referrer leakage and disable unused sensitive browser capabilities such as camera, microphone and geolocation access.

Dependency maintenance

Production dependencies are checked in CI for high/critical npm advisories in addition to lint, TypeScript and production-build checks. Library upgrades still require PDF regression testing because a security update must not silently break document integrity.

Claims PDFBright does not make

PDFBright does not claim to be “military-grade,” “zero knowledge,” independently security-certified or impossible to compromise. A browser-local architecture reduces some document-handling risk, but browser engines, PDF parsers, dependencies and the user's own device still have security boundaries and failure modes.

Future server processing

If heavy OCR later moves to a server worker, PDFBright's architecture requires isolated processing, strict CPU/RAM/time limits, private temporary storage, short-lived signed access, automatic deletion, retryable deletion jobs, document-content-free logs and explicit disclosure before the document is sent.