Contact

Bug reports, corrections and tool suggestions are genuinely welcome. Here is how to reach us and what to include.

Email

The fastest way to get a response is email: hello@devforge.dev

Please use a descriptive subject line. These get answered fastest:

• Bug: [tool name] — [what happened]
• Correction: [page] — [what is wrong]
• Tool request: [what you need]

What to include in a bug report

A reproducible report is usually fixed in a day. An vague one takes weeks of back-and-forth. Ideally:

1. Which tool or page. The full URL is best.
2. The exact input you used. If it is sensitive, reduce it to a minimal example that still reproduces the problem — often that reduction is enough.
3. What you expected to happen.
4. What actually happened. A screenshot helps enormously for rendering or layout problems.
5. Your browser and OS. Behaviour differences between browsers are a real category of bug.

Corrections

If something on this site is factually wrong, we want to know — especially pricing data, which decays quickly, and security guidance, where being wrong has consequences. Tell us what is wrong and, if you can, cite a source we can check. Corrections are prioritised over almost everything else.

Tool requests

New tools get added when there is a real, recurring need. The most persuasive request describes the situation rather than the tool: what you were trying to do, what you tried, and why it did not work. That tells us whether a new tool is genuinely the right answer.

Requests that fit DevForge are things a developer hits regularly, that need no backend, and that can be done entirely client-side.

Things we cannot help with

• Debugging your application. We can help when a DevForge tool misbehaves. We cannot help you debug your own codebase — try Stack Overflow or the relevant community.
• Recovering data you pasted into a tool. Nothing is stored, so there is nothing to recover. Keep your original source.
• Verifying a JWT signature. We deliberately do not do this, and we will not do it over email. Verification requires your secret key, which must never leave your infrastructure.

Privacy, legal and advertising

• Privacy and data questions: see the Privacy Policy.
• Terms of use: see Terms of Use.
• Advertising, including how to opt out of personalised ads: covered in the Privacy Policy.

Response times

This site is maintained alongside other work, so there is no support SLA. In practice: corrections and security issues are handled within a day or two; bug reports within a week; tool requests are triaged and may take longer, or may not be built. We read everything even when we cannot reply individually.