Editorial standards

This page exists so that anyone — a reader, a reviewer, a competitor — can see how the content here is produced and judge it on something more than tone. It is deliberately specific, because the alternative is a paragraph of assurances that carries no information.

Every page is published under the responsibility of Alan Wang, who builds and maintains this site. A named person is answerable in a way a brand is not: if something on a page turns out to be wrong, there is one person to correct it, and the contact page reaches that person directly.

Every claim on a page is checked against the tool's actual behaviour before publication. There is no outsourced content, no template farm, and no bulk-generated page set built by combining a tool name with a search modifier. Tool pages are not spun from one shared paragraph with the nouns swapped: each one is written around what that specific tool does to a file.

A tool ships only after it passes an automated suite that runs in a real browser against real documents — not mocks, and not fixtures that were tuned until they passed. The suite covers four families of assertions:

The suite currently runs well over a hundred assertions. The count is not the point; the point is that the checks are adversarial. They are written to try to make the tool fail, in the places where it has previously failed.

A tool page states what the output preserves and what it loses, in the same breath as what it does. Compression pages say that an already-optimised PDF has little left to give. Crop pages say the page box changes rather than the content. Conversion pages say whether text remains selectable afterwards. When a limitation is known, it is on the page — not in the FAQ of a different tool, and not left for the reader to discover after they have used the output for something that mattered.

If a feature cannot be done well, the answer is to leave it out and say so, not to ship an approximation with a confident label. The about page lists the specific things this site refuses to do, and why.

Guides answer the question in the first screen, before any promotion of a tool. They explain the mechanism rather than only listing steps, because the mechanism is what lets a reader judge whether the advice applies to their situation. Where a claim depends on something external — a clause of the PDF specification, a legal requirement, a print standard — the guide says what that dependency is instead of asserting a rule in the abstract.

Guides state their own limits too. An article about compressing scans says which scans cannot be compressed much, not only which can. A guide that could not be wrong about anything is not telling the reader enough.

Advertising is placed by code, in fixed slots, and is never part of a recommendation. No page here is written in order to attract a particular advertiser, no advertiser sees a page before it is published, and no commercial relationship changes what a page says about a tool, a format or a competing service. Where a comparison is drawn, the basis for it is stated so that it can be checked.

Tool pages and explainer pages carry the date they were last reviewed. That date moves when the page is genuinely re-read against the current behaviour of the tool, not when it is touched cosmetically. Guides carry their own update date. A page that has not been re-read keeps its old date rather than being handed a fresh one.

If a page is wrong, the correction is applied to the page and the review date is updated. Errors are not handled by deleting a page and republishing it at a new address, and a wrong claim is never quietly softened — it is replaced with the correct one, or removed. The contact page explains how to report an error and what makes a report easy to act on.