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: if a claim appears on Utilavo, it has been checked against a citable source or produced from a measurement we can reproduce. Where we have an opinion (for example, choosing a default cipher mode), we say so explicitly and explain the trade-off.

Every published article passes through three checkpoints before it appears on the site:

1. Source verification. Every factual claim is matched to a primary source. Standards references must be the latest revision in force at the publication date; deprecated references are noted as such.
2. Methodology check. Where the article reports measurements (compression ratios, file weights, processing times), the methodology is documented on the methodology page and the raw data is published with the article so readers can reproduce the result.
3. Final read-through. A second editor reviews the article for clarity, structural coherence, and completeness of cross-links. The article ships with a "Reviewed by Utilavo Editorial" stamp and the review date visible at the top.

Research assets follow the same checkpoints with one addition: the source dataset is published as a downloadable CSV alongside the article so anyone can re-run the analysis.

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, and the checks below are run against the codebase before changes go live.

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.

Browser testing

End-to-end browser testing is configured with Playwright against a running build. Two device profiles are defined so pages are checked at both a desktop and a mobile viewport: Desktop Chrome and iPhone 14.

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 pinned in the project manifest 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)
• Original research 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 are based on documented methodology and our own measurements; vendors do not participate in the review.

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.