Fact-Checking Policy

Three kinds of claim

Almost everything we publish falls into one of three categories, and each is verified differently. Understanding which is which is the first step of checking any article on this site.

• Claims about our own games - combo thresholds, power-up durations, point values, difficulty steps. Verified against the running implementation.
• Claims about web platform behaviour - how canvas scales, how touch events fire, what a media query does. Verified against primary documentation.
• Claims about game design in general - why a mechanic feels a certain way, what a design choice trades off. Presented as reasoning and analysis, not as fact, and written so the reader can disagree.

Checking claims about our own games

Every number on a game page is read from the code that implements it, not from a design document. When we write that a combo tier rises every five pickups and drops by one on a miss, that is the behaviour of the scoring module, and it is checked by playing the game and watching the meter rather than by trusting the sentence we wrote earlier.

When a game's balance changes, the game's page is updated in the same change rather than later. A page describing last month's tuning is a factual error, even if it was accurate when published.

Sources for technical subjects

For HTML5, Canvas, Web Audio, touch input, storage and accessibility behaviour we treat the following as authoritative, in this order: the relevant W3C or WHATWG specification, MDN Web Docs, and the browser vendor's own developer documentation. Where those disagree, which happens more often than you would hope, we say so rather than picking whichever supports our point.

• WHATWG HTML Living Standard, for canvas and core platform behaviour.
• MDN Web Docs, for practical API documentation and browser support detail.
• W3C WAI-ARIA and WCAG documentation, for accessibility guidance.
• Browser vendor release notes, where a behaviour is version-specific.

We do not cite an article that summarises a specification when the specification itself is available and readable. We do not cite a source we have not read. We never invent a reference, a study or a quotation.

Claims we will not make

Some claims cannot be verified from where we stand, so we do not make them. We do not publish player counts, popularity rankings or global high scores, because the site has no server that could know them - what we can honestly report is how many times a game has been played on your own device, which is what our popular games page uses and says so.

We make no claims about health, nutrition or the effects of sugar. The candy on this site is a fictional in-game collectible. We are a games site and that subject is outside both our competence and our remit.

We do not cite research we cannot link to, attribute opinions to unnamed experts, or describe something as widely agreed when what we mean is that we agree with it.

Numbers and measurements

Where we quote a performance figure, it is one we measured, and we say what we measured it on. A frame rate with no device attached to it is not information. Where a figure is approximate, we say approximate rather than implying precision we do not have.

Review before publication

Every article is read end to end before publication with a specific checklist: is every factual claim either verified against the implementation or cited to a primary source; does every internal link resolve to a page that exists; does every external link still work; are all numbers current; and is anything stated as fact that is actually an opinion.

How corrections work

When we learn that something is wrong, we verify the correction before changing anything - including corrections sent by readers, which are occasionally wrong themselves. Once verified, the page is updated and its modified date changes.

A correction that changes the meaning of a claim is noted at the foot of the article, stating plainly what the article previously said and what it now says. We do not silently rewrite a claim and leave the reader unaware that it changed.

Minor fixes - typography, a dead link, a clearer sentence with the same meaning - are made without a note, but still update the modified date.

Periodic review

Game pages are reviewed whenever the game they describe changes. Technical articles are reviewed when a browser behaviour they depend on changes, and at least once a year regardless, because the web platform moves and an article that was accurate in 2026 may not be in 2028.

Telling us we are wrong

Email hello@candyarcade.xyz with "correction" in the subject line and a link to the page. Saying what you believe is incorrect and, if possible, what the correct information is makes verification much faster. Corrections are prioritised over all other correspondence.