How we test AntiUpload

Written and maintained by AntiUpload Engineering. Last materially reviewed July 17, 2026.

A long feature list is not evidence that a file tool works. We use repeatable input files, automated checks, and manual visual review to decide what can be described as supported. This page documents the standard behind our tool pages and articles.

Functional testing

Each engine is tested with small deterministic fixtures that exercise the operation it claims to perform: multiple PDF pages, rotated pages, embedded fonts, damaged cross-reference data, images with different codecs, office documents with tables and charts, and media with varied containers, dimensions, frame rates, and audio layouts. A job is not considered successful merely because it downloads. The result must reopen in an independent parser and preserve the properties relevant to that operation.

The repository contains unit, smoke, end-to-end, fidelity, and compression tests. Some large browser operations still require manual review because a byte-valid PDF or video can be visually wrong. Tool pages state known failure cases rather than presenting browser-side processing as identical to a full desktop application.

Privacy verification

“Your file stays on your device” refers to the contents of the file selected for processing. We verify this by inspecting the browser Network panel while a job runs and by testing tools after their required code and models have loaded and the network is disconnected. Page assets, optional analytics, advertisements, and downloadable processing engines can create ordinary network requests; the selected document or media bytes are not posted to a conversion API.

Visitors can repeat the same check: open Developer Tools, select Network, choose a sample file, and run the operation. Our Privacy Policy separately lists the website services that may receive normal web-request data such as an IP address.

Accuracy and comparison claims

Accuracy claims require a named input set, a defined scoring method, the engine version, and the complete result—including failures. We do not treat a marketing example as a benchmark or infer another service's internal behavior from its branding. Comparisons that cannot meet this standard are not published as indexable pages.

Editorial process and corrections

Product documentation is written under the AntiUpload Engineering byline by the maintainer of the implementation. Technical articles distinguish observed behavior, measured results, and opinion. Material updates receive a real revision date; deployment alone does not make every page “new.” If a report identifies an incorrect claim, we reproduce it against the current engine, correct the page, and add a regression test when the issue is testable.

What this methodology does not prove

• It is not a security audit or a legal compliance certification.
• Passing fixtures cannot represent every malformed or vendor-specific file.
• Performance varies with browser, memory, CPU, file size, and input complexity.
• Results should be reviewed before relying on them for legal, medical, or financial work.

Report a reproducible problem

Use the feedback form and include the tool, browser, input format, expected result, and observed result. Do not send a confidential source file; a reduced or synthetic example is safer and usually easier to turn into a regression test.