Text tools by surface and limit

Most catalogues of text tools sort by what the tool produces. That is the right axis when every tool in the catalogue executes the same way. Here it is the wrong one, because the 483 routes resolve to four different execution surfaces, and the surface determines the guarantees: whether the text is transmitted, whether the operation is metered, whether the result is reproducible, and whether the answer can be checked.

Every count on this page is derived rather than asserted. Each route declares an engine family, and a single resolver maps family plus path to a surface. Run over the whole registry it yields 83 local, 345 remote, 38 media and 15 with no engine. Those are the four populations, and they behave differently enough that mixing them in one undifferentiated list would be misleading.

The 83 local routes are deterministic. Each implements a fixed rule, so there is exactly one correct output for a given input, the same input always produces it, and you can verify the result yourself. Case conversion, Unicode normalization, JSON formatting and character removal are all decidable, and a tool that gets one wrong is broken rather than merely disappointing.

The 345 model-backed routes have no single correct output. A rewrite that preserves meaning is one of many acceptable rewrites, and the same input run twice will differ. That is not a defect, it is the nature of the operation, but it changes your obligation as the user: deterministic output can be trusted after a glance, model output has to be read.

Selection is mostly a question of establishing which class the task belongs to, and most tasks answer it immediately.

Step 1

Ask whether the task has a unique correct answer. If it does, it is deterministic work and belongs on a local route, free, unmetered and verifiable.

Step 2

If the answer is not unique, establish whether you need transformation, generation or description. Those are three different instruction sets and choosing wrongly wastes one of five daily runs.

Step 3

Match the route name precisely. The model's instruction is composed from the route label, so the label is the only prompt control available and a specific route outperforms a generic one.

Twenty-four distinct operations, several parameterised rather than fixed.

Character-level

Hidden character removal over a closed set of 14 codepoints, accent stripping, space removal, whitespace minifying, em dash removal and em dash replacement with a configurable string.

Encoding-level

Unicode normalization exposing all four forms, NFC, NFD, NFKC and NFKD, plus URL encoding and decoding. Normalization form is a genuine choice with different outcomes, not a hidden default.

Structural

JSON minify and prettify, delimited text to JSON array with an optional custom delimiter, HTML stripping, Markdown stripping and formatting, line break handling, duplicate line removal, splitting and find and replace.

Measurement

Word counting, token counting, and a scanner reporting 14 invisible codepoints with counts alongside 17 documented phrase patterns.

Parameterised

Case conversion across three cases, px and rem conversion against a root font size defaulting to 16, and a composite cleaner with independent switches for spaces, blank lines and punctuation straightening.

160 rewriters, 134 analyzers and 51 generators. The analyzer total exceeds the count of routes declared as classifiers, because analyzer routes that are not about watermarks or invisible characters are re-pointed to the remote classifier surface by the resolver. That is 64 routes moving, and it is the kind of detail an asserted count would hide.

Two limits apply to all 345 and to none of the others: 5 runs per rolling 24 hours, and an input bound of 1 to 12,000 characters enforced before the model call. Analyzers additionally carry a constraint on what they may conclude, being instructed never to claim certainty about authorship, plagiarism or which model wrote a text, and to report observable signals and limitations instead.

These operate on files rather than on text, so both of the usual framings break. The character bound is meaningless for a file, and the local-processing property does not hold, because the file is uploaded to our media workflow in order for the check or the edit to run at all.

A further 15 routes resolve to no engine: 12 reference pages including this one, and 3 policy pages. Counting those among the tools would inflate the catalogue, so they are counted separately and named.

Comparable directories publish an unqualified claim that data never leaves the device and no server-side processing occurs. Those statements are accurate for catalogues that are entirely client-side, and one of the fetched competitors goes further by describing what does not exist rather than only what does not happen, saying there is no log file recording what was pasted.

We cannot adopt that language, because it would hold for 83 routes and fail for 345. The accurate version is per surface. Local routes transmit nothing, which is a structural property rather than a policy. Remote routes transmit the text, retain none of it, and store only a run counter holding a count and an expiry against a hashed identifier. Media routes receive a file. A single site-wide sentence would have to be false about at least one of those three.

No password, UUID or QR generators, no text-to-image, and no novelty effects. Comparable directories carry them and reach larger headline counts partly that way. Our figures are counts of routes resolved through the surface resolver, described as exactly that.

There is also no pricing, no commercial-use gate and no premium tier, where at least one comparable directory reserves commercial use for a paid plan. And there is no accuracy figure anywhere, for any analyzer, because none has been measured in this system. A catalogue that publishes its exclusions is more useful than one that publishes a larger number.