What we test
Each active tool is reviewed as a complete workflow: selecting a supported local file, changing the visible controls, processing the file, checking the result and starting over. We verify that the page explains the same formats, limits and outputs that the current interface provides.
Testing focuses on representative, non-sensitive files rather than claiming support for every file ever produced. Images include photographs, graphics and transparent artwork. Media checks include short browser-readable audio and video samples. File utilities are checked against known values or repeatable calculations.
Browsers and devices
The site is designed for current desktop and mobile browsers that support the required web APIs. Chrome, Edge, Firefox and Safari can expose different encoders, media codecs and memory limits, so a result that depends on browser support is described with that limitation.
Heavy tasks are reviewed primarily on desktop-class browsers. Mobile checks focus on responsive layout, file selection, visible status messages and whether the workflow remains understandable on a smaller screen.
Result verification
A completed download is opened and checked rather than treating a successful button click as proof. Depending on the tool, review can include dimensions, file type, file size, page count, animation, audio duration, visible crop, transparency or checksum length.
When a tool uses an estimate, the page labels it as an estimate. For example, average video bitrate calculated from file size and duration is not presented as a full codec analysis.
Failure and boundary checks
We check common invalid states such as no selected file, unsupported types, oversized files, impossible trim ranges and browser features that are unavailable. The interface should stop safely and explain the problem instead of producing a misleading download.
Browser processing has real limits. Long videos, unusual codecs, very large batches and professional editing requirements may need desktop software. Those boundaries are part of the documentation, not hidden as exceptions.
Content review
Tool instructions are reviewed against the current controls so visitors do not read steps for a feature that no longer exists. Technical guides are edited for practical usefulness and linked to a tool only when the tool helps complete the described task.
Review dates show when the page and current workflow were checked. They do not imply that every standard, format or browser changed on that date.
Reporting a problem
A useful bug report includes the tool name, browser, operating system, source format, approximate size, selected settings and the visible error. Do not send confidential files. A non-sensitive sample or clear description is normally enough to investigate.
Use the Contact page to report broken controls, incorrect instructions, compatibility problems or factual corrections.