Editorial policy

How these tools are built, checked, and corrected.

DevDesignKit publishes two kinds of page: utilities that run inside your browser, and short reference sheets about web standards. The rules below apply to both.

The guiding idea is simple. A page should be useful to someone who cannot see how it was made, so anything that affects the result is stated on the page itself.

A reader cannot see how a tool was built or where a sheet's facts came from, so this page exists to say so in advance. The rules apply equally to utilities and to reference sheets: utilities are judged by whether their output matches a documented algorithm, and reference sheets are judged by whether each entry matches its standard. When either test cannot be satisfied, the page says so instead of guessing. That is the whole policy in one sentence, and the sections below expand it into the checks that happen before publication and after a report arrives. Nothing on this site claims more than that test can prove.

How a tool is checked before it ships

  • Known inputs first. Every utility is run against inputs whose correct output is already published: an example from the specification, a documented algorithm, or a value worked out by hand.
  • Edge cases are part of the test. Empty input, malformed input, very large input and non-ASCII text are tried before a page goes live, not after someone reports a break.
  • Browser behaviour wins ties. Where a specification and a shipping browser disagree, the tool follows what the browsers actually do, and the page says so when the difference is visible.
  • Limits are printed, not hidden. If a converter drops metadata, rounds a value, or refuses a format, the page names that limit instead of letting it surprise you.

Where the reference sheets come from

  • Standards documents. The CSS, HTML and HTTP pages are written against the published specifications and the MDN reference, not against a tutorial summary.
  • Examples are written for the page. Every code sample was typed for this site and checked in a browser; none are copied from another reference without attribution.
  • Dates are honest. A reference page records when it was last reviewed, so you can judge whether a browser change has overtaken it.

What this site does not publish

  • No invented benchmarks. Speed or quality comparisons between software are not published unless the method and the machine are described.
  • No unverified claims about other products. Nothing here states what a named commercial tool does unless that behaviour is documented by its vendor.
  • No affiliate-driven ordering. Where tools, frameworks or services are mentioned, the order and the wording do not depend on a commission.

Corrections

  • Reports are welcome. Send the page address, what you expected and what happened, along with the browser and version. A reproducible case is fixed fastest.
  • Fixes are made in place. A corrected page keeps its address, and the review date is updated so the change is visible.
  • Nothing is quietly removed. When a utility is retired, the page explains why rather than leaving a dead link.

Advertising and independence

Advertising, where it appears, is kept visually separate from the tools and the reference sheets, and it carries a label. No advertiser is shown a page before publication, and no advertising arrangement decides which utilities are built, which standards are covered, or how a limit is described.

The utilities themselves contain no advertising inside their working area, and nothing you paste into a tool is used for advertising or for anything else: processing happens in your browser and ends when the tab closes.

Icons, screenshots and third-party material

Interface icons come from open icon sets used under their own licences. Any screenshot that shows another product is used to illustrate a documented behaviour, with the source named. If you hold rights to material on this site and want it credited differently or removed, write to the address on the contact page and it will be handled.

How content is verified against published standards

A claim on this site is published only when it can be tied to a named source of record. The JSON tools follow RFC 8259, which fixes the grammar a validator may accept and the number and string rules a formatter may apply. The base64 handling follows RFC 4648, and the HTTP status code sheet follows the IANA registry, the same list browsers and servers use when they answer a request. HTML pages are written against the WHATWG living standard, CSS pages against the W3C specifications, and accessibility guidance against WCAG 2.2. Where a standard leaves a choice open, such as the indentation a formatter should use, the page names the choice it made.

The verification itself is the same test the tools run. An input with a known correct output is passed through the utility, and the result must match the reference exactly.

How updates and corrections are handled

Corrections follow the same path as the original checks. A report is reproduced first, because a claim about a tool or a sheet that cannot be reproduced cannot be confirmed. Once the fault is confirmed, the page is fixed in place, the same models are run again, and the review date moves forward so the change is visible. Nothing that was published is quietly removed, because a removed answer leaves a reader with the same question and no reply.

Small factual slips are corrected first. Deeper errors are fixed last, after the surrounding text has been rechecked.

How machine assistance is handled

Machine-assisted drafting, wherever it is used, never changes the rule above: a statement is published only when it traces to a standard, to a documented browser behaviour, or to the result of running the tool itself. Draft text produced that way goes through the same checks as text written directly, it is verified against the sources linked on the page, and any claim that cannot be confirmed is removed before publication. The reader is never asked to trust a machine summary in place of the specification behind it.

The page always points to the original document, so the check is easy to repeat.

How reference sheets are kept current

Reference pages record when they were last reviewed, and that date means what it says. A web standard moves in part: one section is revised while another stays unchanged, and a browser may ship a feature before the spec that describes it reaches a stable state. So a review date is not a promise that nothing has changed since, it is an honest marker of when the page was last checked against the current text of its sources, which is why the standards list below is rebuilt each time a page is revisited.

When a source revises a rule the site quotes, the page is revisited and the date is moved.

The standards and registries behind these checks