Why We Don't Ask for an Account

The tools on a2zutil.dev exist to solve a two-minute problem: format this JSON, indent this query, convert this string. An account gate adds friction to exactly the wrong moment — right when someone just wants the tool to work, not sign up for a service they'll use for ninety seconds and never think about again.

It's also a real cost on our side, not just a philosophical stance. Accounts mean an auth system, password reset flows, session storage for people who aren't doing anything that needs to persist between visits, and a database of emails and credentials that now has to be secured, backed up, and eventually breach-disclosed if something goes wrong. None of that infrastructure makes the JSON formatter format JSON any better — it's pure overhead that exists to support a login screen nobody asked for.

There's a data-minimization argument here too, not just a convenience one. A service that never asks for an email address can't leak an email address. Every account you don't create is a row that doesn't exist in a database that could someday be breached, sold, or subpoenaed. For tools that people use specifically because their input might be sensitive — a real API response, a real customer record pasted in for formatting — not asking for identifying information in the first place is a stronger privacy guarantee than any policy promising to protect it after the fact.

Friction has a measurable cost too. Every additional step between landing on a page and getting the answer you came for loses some fraction of the people who arrived — that's true of signup forms, email verification loops, and "create a free account to continue" walls alike. For a tool that exists to save someone two minutes, adding a ninety-second signup flow in front of it doesn't just annoy people, it defeats the entire premise of the tool.

None of this means every tool here can get away with zero state, and the Webhook and Temporary Email are the honest exception: they need a URL or an address to exist for longer than a single request, which means something has to be stored somewhere between when it's created and when it's used. The answer there isn't an account — it's a temporary session, identified by an unguessable token kept in your browser's local storage, that expires on its own after a fixed window whether or not anyone remembers it exists.

That's a meaningfully different shape than an account: nothing is tied to an email address or a password, nothing persists past its expiry, and losing the token just means generating a new one rather than going through a recovery flow. It gets you exactly the statefulness the tool needs — a webhook has to still be listening tomorrow, an inbox has to still exist when the email arrives — without any of the account machinery that statefulness usually drags in with it.

Abuse prevention is handled the same way, without accounts: rate limits, message and request caps, and automatic expiry do the job that a signup wall is often used for instead. It's slightly more work to build than "require an account and let auth handle abuse for you," but it means nobody has to hand over an identity just to use a tool for two minutes.

There's a compliance angle too, even though it's not the reason this started: a service that never collects an email address, a name, or a password has a dramatically smaller GDPR and CCPA footprint than one that does. There's no "right to be forgotten" request to process for data that was never linked to an identity in the first place — a temporary session that already auto-expires accomplishes the same outcome as a deletion request, just proactively and for everyone, not reactively for whoever remembers to ask.

It also changes what a security incident would even mean. A breach of an accounts database is a breach of emails, password hashes, and whatever personal data accumulated in profile fields over time — the kind of incident that requires user notification and carries real reputational cost. A breach of a system that only ever held short-lived, randomly-tokened sessions with no identity attached to them is a much smaller, much less sensitive thing to have happen, simply because there was never much sensitive data sitting there to lose.

None of this is an argument that accounts are always wrong — plenty of products genuinely need persistent identity, saved preferences, or billing tied to a person, and building around a session token instead would be the wrong call for them. It's specifically that a two-minute formatting tool doesn't need any of that, and building the account infrastructure anyway just because it's the default pattern would be solving a problem nobody here actually has.

That's the pattern going forward as new tools get added: add state only where the tool structurally needs it, let it expire rather than persist indefinitely, and never make an account the price of using something that doesn't actually require one.