NV ToolkitFormat · Validate · Convert

Editorial Policy

This page describes exactly how everything published on NV Toolkit is produced, verified and corrected — the software the tools are built on, the tests that keep their output honest, the sources the guides cite, and what happens when something is wrong.

Who is responsible

NV Toolkit is a one-person project. NaveenKumar T — Software engineer · builds and maintains NV Toolkit — builds the tools, writes the guides, publishes the pages and answers the mail. There is no editorial board, no content agency and no rotating freelance byline: if something on this site is wrong, one identifiable person is accountable for it, and that person can be reached at hello@nvtoolkit.com. More background is on the About page.

How tools are built and tested

The tools do not contain home-made parsers. Each one is a thin, private browser interface over a named open-source engine that the wider industry already relies on:

  • Formatting and beautifying — prettier (including the PHP plugin), js-beautify, sql-formatter and xml-formatter.
  • Parsing and validating — fast-xml-parser for XML, the yaml package for YAML, papaparse for CSV, JSON5 for relaxed JSON, jsonrepair for broken JSON, and Ajv for JSON Schema validation.
  • Querying and generating — jsonpath-plus and jmespath for expression testing, quicktype for generating typed model classes, cronstrue and croner for cron expressions.
  • Stylesheets — the real compilers: dart-sass (the sass package) and less.js, not a regex approximation of them.
  • Images— each format's reference codec compiled to WebAssembly: mozjpeg, libwebp, libaom (AVIF) and oxipng.

Using the reference implementation is the point: the output you get here is what your own toolchain produces, because it is the same code running in your browser instead of on a server.

Every transform is covered by an automated test suite (npm test), which runs before a release; it currently holds 276 tests. Separately, the worked example shown on each tool page is never hand-typed. A test (src/lib/tools/__tests__/examples.test.ts) feeds each page's example input through that tool's real transform and compares the result with the published output — if a library upgrade or a code change makes the two drift apart, the test fails and the page cannot ship until the example is regenerated from the real output. That is the mechanism behind the claim that the examples on this site are accurate: they are not illustrations, they are recordings.

How guides are written and verified

Each guide answers a specific question a developer actually types into a search box, and is written against the observed behavior of the software it describes rather than from memory. Code samples are executed, regular expressions are run against the strings shown, cron expressions are checked with a parser, and financial formulas are cross-checked against the same functions that power the calculators on this site.

Every guide carries, on the page:

  • an answer-first summary at the top, so the direct answer is visible before the long explanation;
  • a “how this was tested” note naming the version or tool the examples were verified with;
  • a list of sources linking the specifications and official documentation behind the claims;
  • a visible revision date, updated when the content of the page actually changes — not on every deploy.

Sources and citations

Where a guide states what a format allows, the source is the primary document: the RFC, the ECMA or W3C specification, the language reference, or the official documentation of the library in question — not a summary of it on another site. Those references are listed at the end of the guide with direct links, so you can check the original rather than take our word for it. Where behavior differs between implementations, the guide says which implementation was tested instead of presenting one vendor's behavior as the standard.

Corrections

Mistakes get fixed, not quietly buried. If you find an error — a wrong result from a tool, an inaccurate statement in a guide, a broken example — email hello@nvtoolkit.com or use the contact page. A minimal input that reproduces the problem is the fastest possible bug report. When a correction is made, the page's revision date is updated so you can tell that the content changed; substantive changes to the site are also recorded on the changelog. Tool bugs usually turn into a new test case as well, so the same mistake cannot come back unnoticed.

Advertising and independence

The site is free and supported by Google AdSense. Nothing on this site is sponsored content, paid placement, or a paid review: no advertiser can buy a mention, a recommendation, a link, or a place in the catalog. Ads are kept visually separate from the content, labelled as advertising, and never placed inside an editor or between the input and output of a tool. Advertising and analytics storage stays off by default for visitors in the EEA, the UK and Switzerland until consent is given; the details are in the Privacy Policy.

One limit worth stating plainly: the calculators and the finance guides are illustrative. They show how a formula works and what it produces for the numbers you enter. They are not financial, tax or legal advice, they do not account for your circumstances or your lender's rounding rules, and you should confirm any figure that matters with a qualified professional.

Use of AI

We are direct about this. AI tools are used as an assistant during drafting and research — outlining a guide, suggesting phrasing, and helping write and refactor code — in the same way an IDE's autocomplete or a linter is used. AI output is never published as-is and is never the authority for a factual claim.

Before anything is published: every code sample and every tool example is actually executed and its real output is what appears on the page; every factual statement about a format, a specification or a library is checked against the primary source linked in the guide; and the whole page is read and edited by NaveenKumar T, who is accountable for it. Where a claim could not be verified against a primary source or a test, it is removed rather than softened.

Contact

Corrections, questions about this policy, tool requests and press enquiries all go to the same place: hello@nvtoolkit.com. See the contact page for what to include, the about page for who is behind the site, and the terms of use for the legal basis on which the tools are offered.