Ideas welcome

Share an idea

This toolbox is built to grow, and the clearest signal for where it should go comes from the people using it. Found a bug, a mistake, or an inaccuracy? Want a tool that isn't here yet? See a better way to handle something, or a result you'd word differently? Send it, every kind of input is welcome.

What you can send

Bugs, mistakes, and inaccuracies of any kind: a tool that misbehaves, a wrong result, an error in a Learn article, or anything that simply looks off. Feature requests for tools that already exist. Ideas for new tools the toolbox should have. Corrections and additions to the Learn articles, like a clearer explanation, a better source, or a topic that is missing. Or simply a different angle on a problem. Rough is fine; a sentence is enough to start a conversation.

If you're proposing a new tool

One simple test decides it. Every tool here runs entirely in your browser and sends nothing anywhere, so a new tool has to be something a computer can work out just from what you type, by following a fixed, published rule. If it needs to go online, look something up live, sign you in, or remember you, it does not belong here.

Fits: decoding or explaining something you paste in (a token, a certificate, a config, command output), converting between formats, calculating from a standard or formula, or generating from a rule, like a UUID, a hash, or a command line.

Does not fit: anything that has to go online or check something live (testing a real website, querying a live DNS server, scanning an address), anything that needs an account, a login, or saved data, or anything whose answer is not fixed by a published standard.

Not sure which side your idea falls on? Send it anyway and say what it should do. I will tell you honestly whether it fits, and why.

Tools here are small, self-describing modules: a manifest that says what the tool is and where its correctness comes from, one pure function that does the work, and a set of golden vectors, the fixed input-and-output pairs that prove it. A good fit computes locally and deterministically (the same input always yields the same output, with no clock, network, or randomness in the result), keeps anything sensitive on the device, and pins its correctness to a cited source such as an RFC rather than to opinion. You don't need to build any of that to propose one: just describe what it should compute, an example, and the source it rests on.

How to reach me

Email is the channel. Tell me what you found or what you'd like, with enough detail to act on: an example, a link, the exact wording, whatever fits. If it makes the toolbox better, it gets built.

Emailhello [at] ronutz.com
Back to the toolbox