Bugs and feature requests
A GitHub Issue is the most reliable route: it leaves a record, progress is public, and the next person with the same problem can find it. Without an account, a blog comment works too.
Recommended contact routes
If the issue tracker is unavailable, a public note through the repository or blog route is still better than a vague report with no reproduction details.
What helps in a bug report
- The tool page URL and the exact feature involved
- A minimal reproducible input or sample
- The expected result versus the actual result
- Browser name/version and whether it happened on mobile or desktop
- A screenshot or console error if available
Where to send what
This is a one-person project, so there is deliberately only one main channel. Sending things this way makes them hard to lose.
Privacy requests
There are no accounts and input is not sent to a server, so there is no personal data to delete. For questions about how processing works, start with the privacy notice and raise an issue for anything it does not answer.
Copyright and takedown
If something here infringes your rights, open an issue with the URL and the basis for the claim. Removal comes first where the claim is clear; anything requiring judgement is discussed openly in that issue.
Advertising and partnerships
Ad formats that cover a tool's working area or push results out of view are not accepted. Other proposals can go through the repository or blog.
What to expect from a reply
How long does it take?
There is a day job, so immediate replies are not realistic. Tools producing wrong results and layouts breaking on mobile are looked at first. Feature requests are read, but implementation is not promised.
What is out of scope?
Technical support for your own code, custom tool development, and consulting on building a commercial service from this source are not covered. They fall outside what the tools do, so an answer would not actually help.
Found a security problem?
If it could affect other users, describe the impact first rather than posting full reproduction steps publicly. Fixing before disclosing is the safer order.
What not to send
Never include real passwords, API keys, production tokens or customer data, even as a reproduction case. Public issues are indexed by search engines and a posted value is hard to take back. Keep the shape of the value and change the contents.
What makes a feature request useful
Describe the workflow pain
“Add a tool” is less actionable than explaining which repetitive task you want to shorten.
Show expected input and output
Concrete examples help determine scope and implementation feasibility much faster.
Note whether browser-only is possible
It helps to know whether the feature can stay client-side or would depend on an external API.
Review priority
Issues in frequently used tools, confusing security copy, and mobile layout problems are reviewed first.