How we work

Editorial and testing standards

Every published tool and guide should solve a clear task, explain its result in plain language and pass a documented review before it goes live.

Learn more about the site and its purpose on About Plain Tools.

Our publishing principles

Useful first

A page must help someone complete the task promised by its title. Search visibility never excuses an incomplete control, generic explanation or irrelevant recommendation.

Clear and specific

Instructions identify the required inputs, available options and meaning of the result. Examples should fit the tool instead of being reused without context.

Tested behavior

Interactive utilities are checked with normal values, boundaries, empty inputs and representative invalid data. Results are compared with the documented formula, format or expected transformation.

Honest limitations

Pages explain assumptions and important limits. Estimates are labeled as estimates, and tools are not presented as substitutes for legal, medical, financial or other professional advice.

Review process for tools

  1. Define the job. The page is assigned one primary task and a clear user intent before controls or explanatory copy are reviewed.
  2. Exercise every control. Buttons, inputs, selectors, previews, copy actions and downloads are checked for understandable states and useful feedback.
  3. Test representative cases. Review includes a familiar example, an edge case and incorrect or incomplete input where applicable.
  4. Verify the result. Calculations are checked against their formulas. Converters and validators are compared with the format rules described on the page.
  5. Review the presentation. Labels, spacing, keyboard access, mobile layout, result hierarchy and related links are checked before release.
  6. Run release checks. Automated checks cover page structure, metadata, canonical URLs, internal links, scripts, recommendation logic and sitemap inclusion.

Standards for articles and explanations

Guides are written around a specific question or workflow. They should answer the main question early, use descriptive headings, distinguish facts from practical judgment and link only to tools or guides that genuinely help with the next step.

We avoid padding articles to reach an arbitrary length. Repeated boilerplate, keyword lists and sentences that could be pasted onto unrelated pages do not meet our standard. Search terms may shape a page’s title and scope, but wording must remain natural and useful to a reader.

When a subject can change, the page should identify the date or context of the information. Technical explanations should name the relevant formula, unit, encoding behavior or browser limitation when that detail helps someone verify the result.

Privacy and external data

Tools described as local process their working input in the visitor’s browser. If a feature needs current external information, such as geographic place search, that dependency should be apparent from the page and limited to the information required for the feature.

Visitors should not have to create an account for ordinary calculations or conversions. For more information about site data, see the privacy policy.

Corrections and updates

Pages may be revised when a calculation, interface, browser behavior, external rule or explanation changes. A correction should address the underlying template or shared component when the same issue could affect multiple pages.

If you find an unclear instruction or a result that appears wrong, send the page address, the values entered and the result you expected through the contact page. Reproducible reports are prioritized because they allow the behavior to be tested and corrected.

Minimum publication checklist