Processing architecture

Your PDF stays in the browser for the included core tools.

PDFbrix uses a browser-first processing engine with type checks, memory guards and tool-specific PDF operations.

1. File selection and validation

When you choose a file, the tool validates the expected format using both the file selection rules and the beginning of the file content. PDF tools look for a PDF header; image tools check common image signatures. Empty files and files beyond the configured browser-memory guard are rejected before processing.

2. Processing in the active tab

PDF transformations are performed with browser-side JavaScript. The core engine uses PDF libraries loaded by the page and operates on in-memory file data in the current browser tab. It does not post the selected document to a PDFbrix processing endpoint.

3. Output generation

The generated PDF, ZIP, image or text output is represented as a browser Blob and downloaded directly from the active session. Refreshing or closing the page clears the active selection and generated in-memory output.

4. Memory and performance limits

Large PDFs can require several times their file size in working memory, especially when pages are rendered to images. The engine therefore includes per-file and combined-size guards, rendering pixel caps, progress feedback and cooperative cancellation for longer loops.

5. Important tool-specific behavior

  • Compress PDF: the included method rasterizes pages, so selectable text can become image content and already-optimized PDFs may not shrink.
  • Sign PDF: it places a visual signature. It is not a certificate-backed cryptographic digital signature.
  • Crop PDF: it changes the visible crop box. Cropping is not secure redaction and hidden content may remain in the PDF.
  • Extract Text: it extracts existing selectable text. It does not pretend to be OCR for image-only scans.

6. Third-party code and network requests

The current production starter loads pinned PDF helper libraries from established CDNs. Those library requests are separate from document processing. For maximum supply-chain control, a production team can self-host the pinned library files and update the Content Security Policy accordingly.

7. Future server-side tools

If a future feature requires server processing, the interface and privacy policy should clearly say so before a file is transferred and document retention/deletion controls should be defined for that feature. Local and server workflows should never be described as if they are the same.

Open the PDF toolbox