Contact
Send bug reports, requests, or privacy questions to the right inbox.
What to contact about
This form routes to the right inbox based on what you select. Before reaching out, here is a quick guide on what each category covers and what to include so your message gets acted on quickly.
Bug Reports
If a tool is producing incorrect output, a UI element is broken, or a feature stopped working, use the Bug report type. Include the URL of the specific tool page, what you pasted in, what output you expected, and what you actually got. Browser version and OS are helpful but not required. The more specific you are, the faster it gets fixed.
Examples worth reporting: JSON formatter crashes on valid input, JWT decoder shows wrong expiration time, hash output changes on the same input, CIDR calculator returns incorrect subnet masks. If the issue only appears in one browser and not another, note that — it usually points directly at the relevant API or rendering difference.
Technical Issues
Use this category for performance problems, rendering issues, or anything that is not clearly a bug but is blocking you. If the Log Explorer is slow on large files, the Regex Tester is freezing on certain patterns, or a page is loading incorrectly on a specific screen size, this is the right route. Include the page URL and a description of what you observed.
Improvement Suggestions
If a tool works but could work better, suggestions are welcome. Examples: add a copy button to a specific output, support a new hash algorithm in the Hash Generator, add IPv6 support to an IP conversion tool, improve keyboard accessibility in the JSON Editor. Be specific about what you would want and why it would help your workflow.
Tool and Feature Requests
Missing a tool that fits the existing categories? Requests for new utilities are considered based on how broadly useful they are and how well they fit the local-first, browser-based model. Good candidates process data locally without a server round-trip. Requests for API-dependent tools that require storing or forwarding data are generally out of scope.
Useful context to include: what problem you are trying to solve, how often you encounter it, and whether an existing tool on the site partially addresses it. The more concrete the workflow, the better.
General Questions
Questions about how a specific tool works, what algorithm it uses, or how to interpret a specific output belong here. If you are unsure whether your JSON is valid, why a JWT is failing to decode, or what a specific CSP directive means in the CSP Analyzer output, include the relevant data and the question. You will get a direct answer, not a link to documentation.
Security Issues
If you have found a security vulnerability, use the Privacy inbox (privacy@onlinedevtools.app) rather than the general contact address. Include a description of the issue, reproduction steps, and your assessment of impact. Responsible disclosure is appreciated and will be acknowledged. Do not post security issues publicly before reaching out — give reasonable time to assess and patch before any public disclosure.
Privacy Inquiries
Questions about data handling, what is collected, how analytics work, or requests to understand how a specific tool processes your input should go to privacy@onlinedevtools.app. All core tools process data locally in your browser — nothing is sent to a server for processing. The Privacy Policy covers the full data model including analytics and advertising. If you have a specific concern not covered there, reach out directly.
Response expectations
This is an independent platform maintained by one person alongside other work. Bug reports and security issues are prioritized. Improvement suggestions and feature requests are reviewed and logged but may take longer to respond to. General questions about tool behavior typically get a response within a few days. If you do not hear back within a week on something urgent, a follow-up is fine.
There is no ticketing system. Messages go directly to an inbox, not a support queue. Responses may be brief but are direct. If your bug report is detailed enough to reproduce, you may simply get a reply confirming it has been fixed — with a link to verify.
Writing an effective bug report
The most useful bug reports are specific and reproducible. A report that says "the JSON formatter is broken" cannot be acted on. A report that says "the JSON formatter returns a parse error when the input contains a key with a backslash-escaped double quote" can be reproduced and fixed in minutes.
Before submitting, confirm the issue reproduces in a fresh browser tab or private window. Some issues are caused by browser extensions that interfere with clipboard access, local storage, or script execution. If the issue disappears in a private window, note that — it is useful even if the root cause is your environment rather than the site itself.
Include the browser name and version if possible. Chrome, Firefox, Safari, and Edge have meaningful differences in how they handle certain web APIs. A bug that appears in Safari but not Chrome is often a WebKit-specific issue, and knowing that immediately narrows the investigation. On mobile, include the device and OS version as well.
Useful context by tool
For JWT Decoder questions: include the algorithm from the header (RS256, HS256, ES256, etc.) and whether you are seeing an unexpected claim value or a decode failure. Do not include a live production token — a dummy token with the same structure is enough to reproduce most issues.
For CSP Analyzer questions: paste the full header value including all directive names. If a severity rating seems incorrect, note which directive and what you expected. CSP evaluation has many edge cases around directive inheritance and fallback behavior, and the exact directive wording matters.
For Hash Generator questions: specify the algorithm, the input encoding (UTF-8, ASCII, hex bytes), and the expected output if you are comparing against another tool. Different tools handle newline characters and trailing whitespace differently — that is the most common source of hash mismatches when two tools nominally process the same input.
For Log Explorer questions: describe the log format (structured JSON, plain text, syslog) and what you are trying to accomplish. A sample log line with sensitive values replaced is usually enough to reproduce a parsing or filtering issue.
What happens with your message
Your email address is used to reply to your message. It is not added to a mailing list, not shared with third parties, and not stored beyond what is needed to handle the conversation. See the Privacy Policy for the full data handling description. If you are sending sensitive technical data as part of a bug report, redact anything not needed to reproduce the issue before sending.
Why this platform is worth supporting
Online Dev Tools is built on a simple principle: developer utilities should work locally, without accounts, without data sent to servers you cannot inspect, and without paywalls on core functionality. Every tool here processes your data in the browser tab. There is nothing on the server side that sees your JWT payload, your JSON structure, your hash input, or your log data. That is not a policy — it is the architecture.
If these tools have been useful to your work, the best ways to support the platform are: using it without an adblocker when possible, sharing specific tool links with colleagues who would find them useful, or contributing directly via the infrastructure page. New tools and improvements are added based on what is actually useful. Bug reports and honest feedback are the most directly valuable inputs to that process.
Related resources
Before reaching out, these pages may already answer your question: the full tools index lists every utility with a short description, the Learn hub has guides on using specific tools, and the blog covers deeper workflows including log triage, CSP hardening, hashing and HMAC, and WHOIS-based domain investigation. If a tool is not behaving as described in one of those guides, that is a good bug report.