Editorial Standards

Utilavo Editorial is responsible for the accuracy, sourcing, and independence of every guide, research asset, and educational tool page on the site. The team's role is technical: verify claims against primary sources, document methodology where measurements are involved, and keep content current as the underlying standards evolve.

We treat editorial accuracy as a contract with readers: factual claims should be backed by a citable source, and when one turns out to be wrong we correct it (see below). Where we have an opinion (for example, choosing a default cipher mode), we say so explicitly and explain the trade-off.

Before a guide, research asset, or tool page is published or revised, it is checked in three ways:

1. Sources. Claims about standards, cryptography, and file formats are checked against primary sources and linked where a reader would want to verify them. Some older guides do not yet link every source; we add citations as those pages are revised.
2. Tool behavior. Statements about what a tool does, such as its compression levels, metadata handling, or file limits, are checked against the tool's code, and the page is updated in the same change when that behavior changes.
3. Measurements. Utilavo does not yet publish its own benchmark measurements. Research pages are reference data compiled from primary sources, as described on the methodology page, and each is published with its data as a downloadable CSV.

Editorial accuracy on a tools site is not only about prose. If a tool produces the wrong output, the page is wrong. Utilavo is developed against an automated test suite that is committed to the same repository as the site itself. There is no continuous integration server; the checks below are run locally before changes are deployed.

Automated test suite

The project contains more than 35 automated test files, run with Vitest in a jsdom environment via npm test. They fall into four groups:

• Tool logic. PDF merge, split, rotate, page numbering and page organisation; watermarking; table detection and the PDF-to-Word and PDF-to-Excel conversion helpers; hashing, HMAC, cipher, Base64/URL and JSON formatting routines; colour space and epoch conversion; file size formatting.
• API routes. Integration tests covering the server-side endpoints: compress, protect, unlock and repair PDF; PDF to Word, Excel and PDF/A; HTML to PDF; and the image endpoints for compress, convert, resize, rotate, crop and watermark.
• Interface components. The shared building blocks used across every tool: file drop zone, conversion widget, copy and download buttons, mode toggle, tool card and breadcrumb.
• Site integrity and SEO. Assertions on the tool registry, sitemap coverage, structured data, hub-and-child page relationships, and page metadata quality, so a page cannot ship without a title, description and canonical URL.

We deliberately do not publish a pass count or a coverage percentage here. Those numbers change with every commit, and a figure we cannot keep current would be worse than no figure at all.

Code quality gates

Ongoing maintenance

Tools are re-tested when the libraries they depend on are updated; the PDF, image and document conversion stacks are locked to exact versions by the project's lockfile and upgraded deliberately rather than automatically. When a tool's behaviour or supported formats change, the tool page copy and its frequently asked questions are updated in the same change so the documentation and the software do not drift apart.

Utilavo cites primary sources in preference to secondary summaries. Categories of source we treat as primary:

• NIST Special Publications and FIPS standards (cryptography, hash functions)
• ISO/IEC standards (PDF/A archival, document formats)
• IETF RFCs (URL syntax, JSON, MIME, character encodings)
• W3C specifications and recommendations (web standards, CSS, accessibility)
• Library maintainer documentation (MDN, MuPDF docs, sharp docs, pdf-lib)
• Reference datasets published on the Utilavo research index

We avoid citing other tool aggregators, undated blog posts, or AI- generated summaries as authoritative sources. When a primary source is paywalled, we cite it and provide a freely available secondary source for context.

If you find an error on the site, please email [email protected] with the page URL and a description of the issue. We aim to apply corrections within 14 days.

Substantive factual corrections (a wrong statistic, a superseded standard, a misattributed claim) are noted on the affected page with an updated review date and, where the change materially alters a conclusion, a brief corrections note. Minor corrections (typos, broken links, formatting) are applied silently.

Utilavo Editorial does not accept paid placements, sponsored content, or affiliate-driven rankings. Tool comparisons published under the research section compile reference data from primary sources using a documented methodology; vendors do not participate.

Utilavo is supported by non-intrusive advertising delivered through Google AdSense. Ad placements do not influence editorial coverage, rankings, or recommendations. If this policy ever changes, the change will be disclosed prominently on this page and on every affected article.

There is one channel for reporting problems, and it is read by the people who maintain the site. Please include the page URL and, if a tool produced the wrong result, what you put in and what you got back. If a file is involved, describing the file type and roughly how large it was is usually enough. Please do not send us documents containing personal or confidential information.

Report an error: [email protected]

What happens next

1. We try to reproduce it. A content report is checked against the cited source; a tool report is reproduced locally before anything is changed.
2. Fixes ship with a test where possible. When a reproducible tool defect is confirmed, the fix is added to the automated suite described above so the same defect cannot return unnoticed.
3. The page is updated. Substantive factual corrections are reflected on the affected page with an updated review date. Typos, broken links and formatting are fixed without a note.
4. We reply when a reply is useful. If you left an address and the report led to a change (or if we could not reproduce the problem and need more detail), we will write back.

What we cannot do

We cannot recover a file you processed. Tools that run in your browser never send the file anywhere, and files sent to a server endpoint for conversion are deleted after processing, so there is no copy for us to retrieve. If a conversion goes wrong, keep your original and tell us what happened; see the privacy policy for how file handling works, and the methodology page for how measurements published on the site are produced.