Contact form
Use the subject menu to route the message clearly. Please avoid sharing unnecessary sensitive information. For technical issues, page URLs and short reproduction steps are more helpful than long screenshots alone.
Support and feedback
Use this page to request a tool, report a bug, flag a broken link, or ask a privacy, policy, or business question.
The AdeDX catalog keeps growing, which means the best improvements often come from real use: a tool that needs one more control, a page that needs better instructions, a broken link inside a related-tools block, a layout issue on mobile, or a missing utility that would save time in a repeated workflow. This page explains how to contact the site effectively so your message is easier to review and act on.
Tool requestsAsk for missing utilities and explain the exact input, output, and workflow you need
Bug reportsShare page URLs, steps, browser details, and the expected result so issues can be reproduced
Policy questionsUse the page for privacy, legal, advertising, or data-handling questions linked to the site
Business inquiriesDiscuss licensing, partnerships, media, or operational questions in one clear message
Get in Touch
The form stays simple so you can reach the right topic quickly
If you are reporting a problem, include the exact page URL and the action that caused it. If you are requesting a tool, describe the job you are trying to do rather than only naming a feature. Good messages save time because they reduce guesswork.
What helps your message get resolved faster
Include the page URL
A slug or full page link is the fastest way to remove ambiguity when the catalog spans 900 tools.
Describe the action that failed
Tell us whether the issue was a missing button, broken copy action, bad output, layout overlap, or an empty result state.
Mention device and browser
Responsive issues and some copy or paste behaviors can vary between desktop, Android, iPhone, Chrome, Safari, or Edge.
Stay focused on the task
The clearest requests explain the job to be done, not only a feature name. That helps define the right tool behavior.
Do not send sensitive data
Use sample text, example numbers, or masked values if your message refers to work material or internal content.
Requesting a Tool
The best tool requests describe the workflow, not only the name
A request like "please add an invoice generator" is a start, but it still leaves many questions open. A stronger request explains the exact input fields, the output format, what copy or export behavior matters, whether the page should support calculations or validation, and which related tools people would likely use after it. That level of detail helps determine whether the idea belongs as a simple helper, a more advanced calculator, or a different type of page entirely.
Explain the exact input
Tell us what the user enters into the page. Is it raw text, a list, numbers, dates, CSV rows, JSON, measurements, image uploads, or a few structured fields? Input design shapes the entire interface, so it is the first thing that needs clarity.
Explain the output
Describe what should come back. Should the output be one result, multiple metrics, a downloadable file, formatted text, code, a preview, or a reusable summary? Output expectations separate a real utility from a vague idea.
Explain the real use case
The strongest requests include the reason people would open the page. A clear use case helps prioritize features, write better copy, choose the right related tools, and avoid building something that looks fine but solves the wrong problem.
Reporting Problems
Bug reports are easiest to act on when the failure can be reproduced quickly
A short, clear reproduction note is often more valuable than a vague complaint. If a tool gives no output, loads the wrong section, breaks on mobile, shows a stale count, keeps a dead related link, or produces the wrong calculation, mention the exact sequence that triggered it. That allows the page to be retested without guessing.
Helpful bug report checklist
- The full page URL or tool name
- The input you used, or a safe sample version of it
- The steps you clicked or typed before the issue appeared
- What happened versus what you expected to happen
- The device and browser involved
- Whether the issue happens every time or only occasionally
Examples of issues worth reporting
Useful reports include wrong math output, stale metadata that does not match the page, a control that looks visible but does nothing, a broken copy or reset action, a hidden sidebar on mobile, overlapping cards, a "coming soon" fallback, dead links inside related-tools sections, or a page that still uses an outdated control style while the rest of the catalog has already moved on.
These details help keep the site review-ready and usable for both search visitors and repeat users.
Other Inquiry Types
Not every message is a bug report, and that is fine
Privacy and policy questions
If you need clarification about how browser-based processing works, what data a page may or may not send, or how advertising and analytics are handled, use the contact page and mention the exact page or policy section you are asking about. That makes it easier to answer with context rather than generic legal language.
Business and partnership outreach
Use this page for licensing, media, partnership, or operational questions too. Include who you are, what type of collaboration you have in mind, and whether the request is editorial, technical, commercial, or legal in nature.
General feedback
Not every message needs to fit a strict category. If you have input on navigation, content quality, page clarity, broken expectations, or missing categories, that feedback is welcome as long as the message stays clear and specific.
Before You Send
A short checklist can save a long back-and-forth
The site has 900 tool pages, which means even a small naming difference can point to the wrong page if a report is vague. Before you send a message, take ten extra seconds to capture the exact slug, note whether the issue is visual or functional, and decide whether the problem happens every time or only with certain input. That extra clarity usually cuts multiple follow-up questions and makes it more likely the page can be checked in one pass.
Fast pre-submit checklist
- Copy the exact page URL from the address bar
- Write one sentence about what you were trying to accomplish
- List the button, field, or action that failed
- Say whether the issue is wrong output, no output, or bad layout
- Mention mobile or desktop if the page looks broken
- Mask any sensitive values before sharing sample input
What a strong message looks like
A strong bug report is short but precise: "On /tools/binary-to-hex/, the copy button does nothing in Safari on iPhone after I convert 255. Expected the result to copy to clipboard." A strong tool request is just as specific: "Please build a sales tax comparison calculator that supports multiple rates, inclusive and exclusive pricing, and a copy-ready breakdown table." Clear messages let the review start with the actual task instead of guessing what the page was supposed to do.
The same rule applies to privacy or policy questions. Mention the exact page, script, or workflow you are asking about so the answer can stay practical rather than generic.
Frequently Asked Questions
Common questions before you send a message
Can I ask for a tool that combines several existing tasks?
Yes. Composite tools are often useful when people repeatedly jump between pages just to finish one workflow. The more clearly you describe the sequence, the easier it is to judge whether the right solution is a new tool or a better set of related links and controls.
Should I send screenshots?
Screenshots help when the issue is visual, but they work best when paired with the page URL and a short explanation of what you clicked first. Without that context, a screenshot alone can be hard to reproduce.
Will every tool request be built?
No. Requests are judged by usefulness, clarity, overlap with existing pages, maintenance cost, and whether the job is better solved by a stronger version of an existing tool. Even when a request is not built exactly as submitted, it can still shape future page improvements.
Can I report more than one issue in a single message?
Yes, but keep each issue organized. If several problems affect different pages, list them separately inside the message with one URL per line and a short note about each issue.
What if I found a page that still looks outdated?
That is useful feedback. Mention whether the page has old button styling, layout drift, broken spacing, weak instructions, or missing actions so the review can focus on the exact problem rather than only the general impression.
Is email better than the form?
Both work. The form is convenient for structured routing, while direct email can be easier when you already have a detailed note prepared. In both cases, clarity matters more than the channel.