EVIDENCE, NOT BLANKET PROMISES
How we test the tools.
A successful download is only the start. We check document structure, saved values, visible output and the controls around the workflow. Our checks use synthetic files and do not certify every document.
Review scope updated . This page describes our release checks; it is not an independent security or accessibility audit.
Document-level regression checks
Text editing is checked by reopening the export, confirming the replacement is in the content stream, confirming the selected original text is absent and checking neighboring text and page count. Unsupported font characters, shared streams, XFA forms and signed documents have explicit rejection tests rather than silent fallback.
For interactive forms we inspect the canonical field names and values, page widget relationships and appearance streams. For flattening we require no remaining field widgets and compare the rendered page. The public worked examples and reference files let you repeat a small subset of those checks.
Browser workflow checks
Release QA opens individual tool pages in desktop Chromium, selects synthetic files, uses the workspace controls, waits for completion and checks outputs. Regression scenarios include the encoder module, editable OCR corrections, visible form controls, initial preview readiness, page changes and stale output invalidation. Module startup checks establish that a workspace opens; they are not exhaustive functional coverage of every setting.
File selection in automated QA uses synthetic browser File objects. It does not certify the operating system file picker, downloads folder integration or every browser extension. OCR loads its worker and language data (a few megabytes) before results appear.
Rendering, responsiveness and archival validation
PDF fixtures are rendered separately from their data checks to spot clipping or missing appearances. Responsive checks look for horizontal overflow at representative phone, tablet and desktop widths. Emulated viewport checks do not replace testing on real iOS and Android devices or complete assistive-technology review.
An image-based PDF/A-2b regression fixture is checked with veraPDF. A passing fixture does not certify every generated archive: independently validate each important output against the profile requested by the recipient. PDF repair and structural checks are not malware scanning or signature verification.
Privacy, caching and deployment checks
We review code paths to keep selected file contents and filenames out of analytics payloads, test scoped retirement of old service-worker caches and use content-versioned scripts and stylesheets. Contact submissions are a separate network workflow described in the privacy policy. These engineering checks are not a penetration test.
Source validation checks existing paths, internal links, metadata, structured-data syntax and sitemap targets. Production HTTPS redirects, response headers, actual deployment contents and real-user performance must be checked on the deployed host; a local build cannot prove those server behaviors.
What we do not claim
No universal conversion accuracy, perfect OCR, guaranteed compression savings, certification of every output, completed real-device compatibility matrix or guaranteed search ranking. Structured data must match visible content and eligibility rules. FAQ markup and an LLM-readable summary are not evidence of a ranking increase.
For important files, keep the original and validate the result in the app or process that will receive it. See compatibility and limits or troubleshooting. Report an issue with the tool URL, browser and symptom; avoid sending confidential file contents.