PixelPDF

Security overview

This overview describes safeguards visible in the application code. It is not a security certification, independent audit, or guarantee that every deployment has the same controls.

File validation and processing

Uploads are streamed to server-created per-request temporary directories. The conversion worker checks supported file signatures and operation-specific requirements rather than relying only on a filename extension. Processing runs in a Node.js worker thread with configured memory and execution limits.

The default total upload limit is 50 MB in this deployment configuration, with a configurable range of 10–200 MB. Tool-specific limits also apply, including at most 20 images for image workflows, 50 PDF pages, and a 300 MB output limit.

Temporary files and cleanup

Temporary file writes use restrictive file permissions on supported systems. The application attempts to remove the job directory on failure and after the response stream finishes or closes. A periodic cleanup checks for old PixelPDF job directories older than four hours.

Cleanup is best effort. Hosting storage, backups, abrupt termination, and infrastructure snapshots may follow separate rules that are not controlled by this application.

Request handling

The conversion route checks browser fetch-site and request-origin information when supplied, applies request and file limits, and returns generated files with no-store and content-type protection headers. Error responses avoid returning internal stack traces or document contents.

The application logs a generic worker failure name for server-side troubleshooting; it does not intentionally log uploaded file contents or submitted password values.

Practical limits

A worker thread is not a separate operating-system security boundary. File parsers can contain vulnerabilities, and no claim is made that malicious files cannot exploit a software defect. Keep software and deployment dependencies updated, and do not upload material unless you are authorized.

Password encryption does not prevent an authorized recipient from copying or redistributing an opened document. Visual edits, signatures, watermarks, and cropping are not substitutes for cryptographic identity checks or secure redaction.

HTTPS and reporting

The configured public site origin uses HTTPS. Before uploading sensitive material, verify that your browser is connected securely to the expected site; the code repository alone cannot verify a specific host's certificate or network configuration.

The Contact page shows a direct email option only when the deployment has configured one. Do not include passwords or confidential files in a security report.