Define the job and its limits
We keep each tool focused on one task. Before publishing, we document supported inputs, deliberate limits, and cases the tool should leave for review instead of guessing.
How we test tools
A tool should do one clear job, explain its limits, and make its output practical to review before you share it.
Last updated October 27, 2026
Our review approach
Got A Tool is created and maintained by Yusuf Taha Luleci. The checks below guide how we review a tool before publishing and when changing its file-handling behavior.
Use representative inputs
We test normal inputs alongside malformed files, unsupported formats, empty values, size limits, and edge cases that could otherwise create a misleading result.
Inspect the downloaded result
When a tool creates a file, we check the resulting file itself: its structure, rows, fields, or visible content as appropriate. A successful button click alone is not enough.
Keep reviewable data reviewable
If a value cannot be interpreted safely, the intended behavior is to identify it for review or preserve it unchanged. We avoid silent format guesses and silent deletion.
Check local processing claims
For tools described as processing a selected file locally, we review the processing path and browser network activity during the tested workflow. Advertising, consent, and analytics are separate site services and are described in the Privacy Policy.
Check the page people actually use
We review the live browser flow, mobile layout, accessible controls, server-rendered page details, and nearby tools that could be affected by a shared change.
What this means for you
Read each tool's instructions and warnings before downloading a result. Supported formats and limits vary by tool, and a review message is a signal to check that input rather than a failure to work around.
These checks do not make a tool a substitute for professional, legal, security, or records-management advice. Keep an original copy of important files and review output before using it in a critical workflow.
For details about cookies, advertising, analytics, and local file processing, read the Privacy Policy.
Clear boundaries
What a successful result does not prove
A tool should make its useful boundary clear rather than imply a broader guarantee. These are the checks users still need to make around a completed download.
Not a release approval
A report, cleanup, or conversion does not decide whether a file is appropriate for a recipient, policy, or legal requirement.
Not a recovery promise
A tool can preserve, remove, or flag only the structures it explicitly supports. Keep the original until you have reviewed the result.
Not a speed guarantee
Published file and size limits are guardrails. Browser memory, device performance, and the source file still affect a local workflow.
Practical capacity notes
For a few heavier workflows, we publish the guardrails the tool actually applies. These are safety limits, not time or speed promises: available browser memory and device performance still vary.
Merge PDF
2–20 PDF files · 52,428,800 bytes per file · 157,286,400 bytes total · 1,000 pages
The tool stops before merging when a stated file, size, or page limit is exceeded.
Checked against the current guardrail on October 3, 2026.
Open toolVertical Image Stitcher
Up to 30 JPEG, PNG, or WebP images · 20,000,000 bytes per image · 16,000,000 output pixels per part · 8,192 px maximum edge
Large results split only between images. One image that exceeds either canvas guardrail is rejected clearly.
Checked against the current guardrail on October 3, 2026.
Open toolXML Sitemap Splitter
Plain XML smaller than 50,000,000 bytes · 1–50,000 URLs per output sitemap
Malformed entries stop the download instead of being omitted, and the ZIP includes every generated part plus its index.
Checked against the current guardrail on October 3, 2026.
Open toolFound a problem?
Send the tool name and a short description of what happened. Do not include private files, passwords, or sensitive information.
hello@gotatool.com