Word tools

Someone stuck on seven tiles in a word game and someone checking whether "quixotry" is really a word are close enough to the same visit that they belong under one roof, the way the developer tools sit together because they are all "do one small thing to a string" even though a hash and a UUID have nothing else in common.

What unifies this family is the material, not the operation: letters and words, rather than PDFs or images. As more word tools land here, that is the test each one has to pass — does it work on the word itself, not on a file that happens to contain one.

A rack of letters for a word game is a small thing to worry about, and it is still not something this site sends anywhere. The dictionary these tools search is downloaded once, as plain text, and every search after that is arithmetic in the tab rather than a request — the network panel during a search is the way to check that rather than a claim to take on trust.

That also means there is no server cost per search, which is why nothing here is metered, queued or capped at some arbitrary count of lookups. A million searches cost the same to run as one, because they are not requests to begin with.

A file-based converter cares about bytes: a container format, a codec, a compression scheme. A word tool cares about none of that — it needs a dictionary, an idea of what a "match" means for the specific question being asked, and nothing else. That is a much smaller problem than a converter, which is part of why a family built around it can hold several small tools without any one of them growing complicated.

The trade-off runs the other way too. A converter takes a file whose shape it already understands and produces another one; a word tool takes something as loose as "some letters" or "a string" and has to decide, on its own, what a useful answer even looks like. Unscrambling a rack answers "what can this build"; a future tool comparing two blocks of text would answer a completely different question using the same raw material — text — which is the actual thread connecting everything that will live under this hub.

The developer family answers "do this specific operation to a string a program produced" — decode this token, format this JSON. This family answers a plainer kind of question, the sort a person rather than a program asks: what words can I make, is this spelled the way I think it is, what changed between two drafts. Neither belongs inside the other, which is the same reasoning that kept the QR family separate from both.

It also sits differently in how it gets used. A developer tool is usually one stop in the middle of a task that continues somewhere else — a terminal, an editor, a deployment. A word tool is more often the whole task: someone arrives stuck on a rack of letters, gets an answer, and is done. That difference is part of why this hub is built to stay simple rather than to accumulate the kind of settings a developer tool collects over time.