1. Confirm the capability
Code and the factual matrix record formats, controls, observable results, and limitations. Published copy must not expand that scope.
( Transparency )
Editorial and testing methodology
The process used to keep published claims aligned with what the tool actually does.
Verification workflow
2. Test with controlled images
Project-owned JPEG, PNG, WEBP, HEIC and TIFF fixtures, an invalid file and controlled batches check dimensions, signatures, transparency, cancellation and export, including AVIF and a size limit in KB. WEBP output appears only when the browser supports it.
3. Exercise browsers and screens
Essential flows are tested in desktop and mobile profiles. Emulated results are identified as such, and the pending physical-device matrix remains disclosed.
4. Review content and publication
Landing pages, articles, metadata, FAQs, and structured data must describe the same behavior with visible dates and limits.
Editorial rules
- Separate general photography concepts from features actually available in the editor.
- Use reproducible product tests and primary sources for external concepts when needed.
- Produce real tool screenshots with project-owned images without simulating unavailable controls.
- Review EN and PT-BR for meaning and natural phrasing while preserving the same facts and limits.
- Record limitations and correct content when product behavior changes.
Code and fixtures
Automated checks use controlled images and observable results.
Browser
Flows, accessibility, and responsive dimensions are exercised in a browser.
Real screenshots
Visual comparisons come from the running interface and are reviewed before publication.
What does the checking
- Capability registry
- lib/image/productCapabilities.ts lists the formats, controls and limits of each tool. Page format notes are written from it, and an automated test checks the list of publishable outputs.
- Claim auditor
- A script reads all published text and blocks unsupported phrases: AI, offline operation, "no limits", "all browsers", "lossless" and WEBP without the browser condition. It is part of the project's check (npm run check).
- Scripted screenshots
- scripts/capture-product-screenshots.mjs opens the running site, loads the demo photo, opens each panel and saves the captures in Portuguese and English. No interface image is put together by hand.
- Media budget
- Another script checks that every referenced image exists, that no rejected image comes back into use and that each file fits its maximum size.
An example: the November 2026 review
When the new editor went live on every page, the content was checked against the code again. What was found and fixed:
- The filter, vignette, grain and noise pages described controls the editor does not have (sepia, duotone and cross-process filters; a vignette with "radius" and "softness"). They were rewritten from the code: seven editable filters, a vignette with amount, midpoint, roundness and feather.
- Copy said noise reduction was a 3×3 average. The new editor uses a guided filter on brightness and a blur only on color; the auditor rule that blocked "preserves edges" was replaced by one that blocks AI claims.
- The crop page said a crop could be undone inside the editor. The crop is written on confirm; the answer was corrected.
- Screenshots showed the previous editor. They were redone by script, in Portuguese and English, and the old ones were deleted.
Details are in the changelog.
Last reviewed: 7 November 2026.
This methodology describes how claims are verified. What the editor is, what it does not set out to do, and who answers for it are on the About page.