Contact

One person maintains these tools, so there is no contact form, no tracker and no support queue — email works better than any of them.

Email: [email protected]

Expect a reply in a day or two. A form field would only re-type what a mail client already does well, and posting your message through this site would mean running the one thing the site otherwise avoids: a server that receives what you wrote.

Reporting a bug

Most reports are one of two kinds — a tool refuses input it should accept, or it accepts input and gets the answer wrong. Both are usually fixable in an evening if the report contains enough to reproduce them:

• Which tool, ideally as the URL from the address bar.
• Your browser and its version number, and whether it is desktop or mobile. "Firefox 141 on Linux" is enough; "latest Chrome" is not, because the bug may be in a specific release.
• The exact input that failed, character for character — see the note below about redacting it first.
• What you expected, and what actually appeared, including the wording of any error line the page showed.
• Anything in the browser console. Open the developer tools, reproduce the problem, and copy the red text if there is any.

Whitespace, line endings and invisible characters are the usual culprits, which is why the exact input matters. A trailing newline, a non-breaking space pasted from a document, a CRLF ending or a byte order mark at the start of a file will each change what a parser does. If your mail client insists on reformatting the sample, attach it as a plain text file instead of pasting it into the message body.

Please redact before you send

Do not send real credentials or real customer data. Nothing you paste into a tool reaches this site — that is the whole design — but an email is an ordinary transfer to a mailbox, and a token or a personal record in one is a disclosure you would have to explain to someone.

A redacted sample is nearly always enough, because these bugs live in the structure of the input rather than its meaning. Keep the shape and replace the content: swap names, addresses and identifiers for made-up ones of the same length and character set, and keep the field names, nesting and ordering exactly as they were. For a JWT, replace the claim values and the signature segment with equivalent-length nonsense — the decoder only cares about the three segments, the Base64url alphabet and the padding, so a fabricated token reproduces a parsing bug perfectly. If a token with a live signature has already gone somewhere it should not, treat it as compromised and revoke or rotate it rather than hoping it expires quietly.

Smaller is better as well as safer. If you can cut a 4,000-line document down to the twenty lines that still show the problem, that reduced case is the most useful thing you can send, and it usually tells you what the bug is before you finish making it.

Feature requests

Worth asking for: another format the existing tools could handle, a clearer error message, an option a tool is missing. Not planned, on principle: anything that needs your data sent to a server, an account system, or a stored history of what you converted. Signature verification for JWTs and JSON Schema validation are deliberate omissions rather than oversights — the reasoning is on the about page.

Business

For advertising or partnership enquiries, use the same address with "advertising" in the subject line.