Skip to content
AI Viewer
Testing and ratings

How we review AI tools

A rating is useful only when readers can understand the evidence, tasks, trade-offs, and editorial judgment behind it.

Effective and last updated: July 11, 2026

Evidence comes before the verdict

We evaluate a tool from the perspective of the people most likely to use it. Before assigning a verdict, we define the target user, the job they need to complete, and the alternatives they are likely to consider. We then gather the strongest evidence available and identify its limits.

Our evidence labels

Review pages published or materially updated under this policy should make their evidence level clear:

  • Hands-on tested: an editor directly used the product and completed defined tasks. The page should identify the test date, plan or access level, tasks, and important limitations.
  • Research-based evaluation: the conclusion is based on official documentation, pricing, release notes, credible independent sources, and comparative analysis, without enough direct use to claim a hands-on test.
  • First look: a time-sensitive assessment based on limited access or an early release. It is provisional and should be revisited.
  • Reference page: a factual profile or structured comparison. It may help with orientation, but it is not a hands-on review unless explicitly labeled as one.

If a legacy page does not include a test record, readers should treat it as a research-based evaluation—not evidence that every listed feature or task was personally tested.

The review process

  1. Define the decision. We identify the intended user, core use case, relevant competitors, and the questions the review must answer.
  2. Verify the basics. We check current pricing, plan limits, supported platforms, privacy information, and major capabilities against primary sources.
  3. Design representative tasks. When we have access, we use tasks that resemble real work rather than prompts designed only to produce an impressive result.
  4. Record the conditions. We note the date, product version when available, plan, device or platform, important settings, and access limitations.
  5. Observe outcomes and failure modes. We look at output quality, reliability, corrections required, friction, speed, and where the tool breaks down—not only its best result.
  6. Compare credible alternatives. A recommendation should explain what is different and who would be better served by another option.
  7. Review the conclusion. The final verdict is checked against the evidence, commercial disclosures, and the needs of the target user.

What we score

Our overall score uses a five-point scale and an editorial assessment of six decision factors. Weighting may change when a category has different priorities, but the page should explain any material departure.

  • Task performance (30%): the quality and usefulness of results on representative work.
  • Ease of use (20%): setup, learning curve, interface clarity, and effort required to reach a usable result.
  • Reliability (15%): consistency, errors, stability, and how much checking or rework is required.
  • Value (15%): price, plan limits, usage allowances, and value compared with practical alternatives.
  • Privacy and controls (10%): available privacy information, user controls, data settings, and relevant safeguards.
  • Support and fit (10%): documentation, integrations, accessibility, and suitability for the target audience.

A weighted result informs the rating; it does not replace human judgment. If evidence is too limited to support a defensible score, the page should remain unscored.

How to read the score

  • 4.5–5.0: exceptional for the stated audience, with limited meaningful drawbacks.
  • 4.0–4.4: strong, with clear benefits and some trade-offs.
  • 3.0–3.9: useful in the right circumstances, but significant limitations affect the recommendation.
  • 2.0–2.9: weak overall or suitable only for a narrow case.
  • 1.0–1.9: does not perform its central job reliably enough to recommend.

Scores are not universal rankings. A lower-rated specialist tool can still be the better choice for a particular workflow, budget, language, or privacy requirement.

Access, free products, and commercial relationships

We may test a free plan, pay for access, receive temporary access from a provider, use a demonstration account, or evaluate public materials. The relevant access condition should be disclosed because it can affect the experience. Free access, an affiliate relationship, sponsorship, or advertising does not guarantee coverage, inclusion, a rating, or a positive verdict.

Evidence and screenshots

Where practical and lawful, hands-on reviews should include screenshots, sample inputs, output excerpts, measurements, or other evidence of the work performed. We may omit or redact evidence that contains personal data, confidential material, copyrighted output, account information, or unsafe content. An omission should not be replaced with a stronger claim than the remaining evidence supports.

Freshness and retesting

AI products change frequently. A review should show when it was published, updated, or last verified. We prioritize retesting when pricing, core models, plan limits, ownership, privacy terms, or a central feature changes. A score reflects the product and evidence available at the date shown; it is not a permanent guarantee.

Corrections and challenges

Providers and readers may challenge a factual claim or submit newer evidence. We consider that information, but the publication controls the final wording and verdict. Material errors are handled under our Corrections Policy.

Contact the review desk

To ask about a test, disclose a product change, or identify a possible error, email [email protected] and include the page URL and supporting evidence.