Thirty-Six Browser Tools, One Typed Catalog

I launched x70 Tools in July with 36 small browser utilities across data, encoding, text, generators, images, and documents.

The visible product is a catalog of formatters, converters, inspectors, and generators. The architectural question was how to stop 36 routes from becoming 36 unrelated mini-apps.

The answer was a typed catalog that owns the public identity of every tool.

One record feeds every discovery surface

Each tool definition carries the fields the rest of the site needs: slug, name, description, category, icon, search terms, and whether it should be featured.

That one registry drives:

• the catalog cards and filters;
• /tools/[slug] route generation;
• titles and descriptions;
• the sitemap;
• category counts and navigation.

Adding a tool still requires implementing the workbench. It does not require remembering to hand-edit several parallel arrays with slightly different names.

This is a small example of an important product rule: if several interfaces describe the same public object, they should derive from the same record.

Local processing is a product constraint

The site describes itself as privacy-first because the tools process pasted text and selected files in the browser. That claim has to influence the implementation.

Text conversion, image canvases, PDF operations, hashing, and generators run in client components. Inputs stay in component memory and disappear on refresh. The catalog does not send tool contents to analytics, and the current site does not load a general analytics product.

“Runs locally” is not a certification and it does not mean the page has no network requests. The application itself, shared brand assets, fonts, and status information still arrive over the web. The bounded claim is about the tool input and transformation path.

If a future utility genuinely needs a server, the interface and privacy text will need to say so instead of inheriting the local label.

Browser tools still need resource policy

Keeping work on the device moves responsibility; it does not remove it.

A visitor can select a huge PDF, paste an expensive regular expression, or ask a canvas to allocate more memory than the tab can tolerate. Without limits, a privacy-preserving tool can still freeze the browser.

The implementation therefore sets local size, page, canvas, and output limits. Regex evaluation uses a disposable Web Worker with a hard timeout so a pathological expression can be terminated without locking the main interface. Heavy tool families are code-split and loaded only when needed.

Those limits are part of the UX. The error should name the local boundary and offer a smaller next step rather than fail as an unexplained tab crash.

Shared primitives prevent 36 design systems

The tools need different controls, but they share a small interaction grammar: input and output panels, copy and download actions, file drop zones, status messages, option fields, and reset behavior.

Reusable primitives keep keyboard focus, labels, spacing, and error treatment consistent. The tool-specific component can focus on the transformation instead of rebuilding a form shell.

This is also where restraint matters. A JSON formatter does not need a dashboard. A timestamp converter does not need a card stack. The user should be able to arrive, understand the inputs, run the operation, and leave.

The count is a snapshot, the catalog is the contract

Thirty-six was the launch inventory and remains the current catalog count while I write this retrospective. It is not the product goal by itself.

A larger count would be worse if routes became duplicated, unsafe, or difficult to understand. A smaller collection of dependable utilities is more valuable than a directory inflated with thin variations.

The typed catalog makes that discipline possible. It gives every tool one public identity and gives the rest of the site one place to learn about it.

The tools do many small jobs. The registry does one large one: it keeps the collection coherent.