Editorial Policy & Engineering Standards

🔴 1. Who Writes and Builds This Site

Prime Tool Hub is a one-person project. Every tool, article and line of code on this site is written and maintained by a single ICT teacher working from Sri Lanka, not by a rotating pool of freelance writers. There is no editorial board, and pretending otherwise would be dishonest.

That has an obvious downside: updates are slower than a funded team could manage, and a bug reported on a Tuesday may not be fixed until the weekend. It also has an upside worth stating plainly. Nothing gets published because it ranks well or because a topic is trending. A tool gets built when a real problem keeps coming up in a classroom or in a browser tab, and background details are on the about the founder page.

🟡 2. How Tools Are Tested Before Publishing

Tools are not published simply because they run without an error in the console. Each one is checked against known-correct output before it goes live.

• Verified against a reference: Calculators and converters are tested against a source that is already trusted, not against themselves. Hash output is compared to a command-line result, logic simplification is compared to a hand-worked Karnaugh map, and date or cron parsing is compared to the specification rather than to intuition.
• Deliberate bad input: Every tool is fed empty fields, oversized files, wrong file types and pasted content from word processors, because that is what real input actually looks like. A tool that silently returns something wrong is treated as more serious than one that visibly fails.
• Real devices: Testing happens on a mid-range Android phone as well as a desktop browser. A layout that only behaves on a fast machine has not been tested.
• Stated limits: Where a limit exists, such as a practical file size ceiling imposed by browser memory, it is written on the tool page itself instead of being left for the user to discover.

Two examples of this policy in practice: a password generator on this site was rewritten after testing showed its shuffle was statistically biased, and a truth table tool was rebuilt because its expression parser mishandled certain operator combinations. Both were corrected before most users would ever have noticed.

🟢 3. Use of AI in Our Content

AI writing assistants are widely used across the web, so it is fair for you to ask where this site stands. AI tools are sometimes used here for drafting help, phrasing and proofreading. They are never used to generate a finished page that is published without review.

Every technical claim, every worked example and every number on this site is checked by a human before publication, and any output produced by a tool that appears in an article is generated by actually running that tool. Nothing is published on the assumption that a model got it right.

🔴 4. Privacy and Client-Side Processing

Privacy on this site is an architectural decision rather than a promise. Nearly every tool runs entirely inside your browser using standard web APIs, which means the file you open, the text you paste and the key you check never travel to this server. There is no upload step to trust, because there is no upload.

You can verify this yourself rather than taking it on faith. Open a tool, disconnect from the internet, and use it. If it still works, no data was being sent anywhere. The technical reasoning, including what this approach protects you from and what it does not, is covered in the guide on securing API keys with client-side data processing.

An honest limit: a small number of features cannot run locally, and any page where that applies says so on the page.

🟡 5. Advertising and Editorial Independence

The site is free, with no premium tier, no account requirement and no email wall. Running costs are covered by display advertising.

Advertising has no influence over editorial decisions. No advertiser has ever paid for a mention, a review or a link on this site, and no article is written to attract a particular category of ad. Where an external product or standard is referenced, it is because it is genuinely relevant, and any commercial relationship would be disclosed in the article itself.

Ad placement follows a rule set deliberately: ads never sit inside a tool interface, never appear between an input field and its result, and never imitate a button. If an advertisement on this site ever looks like part of a tool, that is a bug worth reporting.

🟢 6. Corrections and Reader Reports

Software written by one person contains mistakes. The useful question is what happens next.

If you find a wrong result, a broken feature or an unclear explanation, send the input you used along with the result you expected. Reports that include the exact input are usually resolved within a few days, while a report saying only that a tool is broken can take far longer to reproduce.

When a factual error is fixed in an article, the page is corrected and its update date is changed rather than the error being quietly deleted. When a tool produces incorrect output, the fix takes priority over new work in progress. Several tools on this site exist in their current form specifically because a reader took the time to report a problem, and the contact page is the fastest route.

🔴 7. Keeping Pages Current

Browsers change, and a technique that worked in one release can quietly stop working in the next. Pages here are reviewed periodically rather than left to age, and the review checks that the described steps still match what the tool actually does, that external references still resolve, and that any standard mentioned is still current. Web platform behaviour is checked against MDN Web Docs, and where a protocol or format is involved, against the relevant RFC specification.

When a tool can no longer be maintained properly, it is retired rather than left online in a broken state. A smaller set of tools that work is more useful than a large catalogue that cannot be trusted.