The KitBoxDev privacy-first manifesto: local processing, zero egress

Somewhere in your organisation there is a policy document that says production secrets must not be pasted into third-party websites. Somewhere else, there is an engineer with a broken JWT, a deadline, and a search box. In 2026 that gap stopped being a cultural problem and became a network one: egress filtering, browser-extension allowlists, and DLP rules that fire on anything shaped like a private key. The developer utility website — that decade-old category of “paste your thing here, get your thing back” — is now a compliance surface.

We built KitBoxDev around a single constraint that makes the entire question moot. Every tool runs in your browser. There is no server-side processing, no database, and no account system. Every tool executes entirely on your device. This post is the manifesto behind that constraint, and the honest engineering account of what it does and does not protect you from.

Key Takeaways

Principle	What it means in practice	Why it matters in 2026
No server, no egress	Your input is never transmitted anywhere, because there is no endpoint to transmit it to	A tool that cannot receive your data cannot leak, log, or subpoena it
Verifiable, not promised	Open the Network tab and watch nothing leave	Privacy policies are prose, an empty request log is evidence
No accounts	Nothing to correlate a paste with a person	Identity is the join key that turns a leak into an incident
Static delivery	Plain client-side code served as static assets	Fewer moving parts is fewer places for a breach to originate
Rotate anyway	If a real credential touched a browser, treat it as exposed	Local processing narrows the blast radius, it does not erase the event

Data-egress policy is now the deciding factor in whether a developer utility is usable at work at all.
Client-side-only is not a privacy feature that could be toggled off later — it is the architecture, and there is nowhere for the data to go.
The threat you are actually managing is not “does this site look trustworthy,” it is “what does this site’s server receive.”

The 2026 problem: egress is policy now, not preference

For most of the last decade, the risk of pasting a token into a random online decoder was hypothetical in the way that lots of security risks are hypothetical. The tool probably did the work server-side. The token probably went into an access log. The log probably rotated. Nobody probably looked.

Three things changed that calculus, and they compounded.

Secrets became machine-detectable. Credential scanning is now table stakes across source hosting and CI. Once a platform can recognise a private key or an API token by shape, so can a DLP appliance sitting on your egress path — and so can anyone else who ends up holding the log file.

Automated exploitation closed the window. The gap between a credential being exposed and being used is no longer measured in weeks. If a live token crosses a boundary you do not control, “we will rotate it next sprint” is not a plan.

Policy caught up. Stricter data-handling regimes turned “an engineer pasted customer data into a formatting website” from an embarrassment into a reportable processing event. The compliance question is not whether the site was malicious. It is whether you can demonstrate where the data went. For most utility websites, the honest answer is: we do not know, and we cannot find out.

That is the context behind the discussion you have probably seen on developer forums this year — teams comparing egress-allowlist entries, asking which formatter, decoder, or converter is genuinely local, and increasingly answering the question by opening DevTools instead of reading the About page. It is a good instinct. It is exactly the instinct we designed for.

Did You Know? The browser has shipped a real cryptographic primitive set — SHA family digests, HMAC, RSA, ECDSA, Ed25519, AES-GCM, PBKDF2 — natively since the Web Crypto API landed. Signing and verifying a token in a tab is not a shim around a server, it is the same primitive your backend uses.

Source: MDN, Web Crypto API

The manifesto

Seven commitments. They are ordered by how much they constrain us, not by how well they market.

1. No server means no breach surface

The strongest privacy guarantee available to any tool is structural: not collecting the data. We do not encrypt your input in transit, because there is no transit. We do not secure the database, because there is no database. We do not have a retention schedule, because there is nothing retained.

This is worth stating precisely, because “we don’t store your data” is the most abused sentence in the category. A server-side tool that promises not to store your input still receives it. It sits in memory, in a request log, in a load-balancer trace, in a crash dump, in whatever the CDN in front of it decided to buffer. “We don’t store it” describes an intent about one stage of a pipeline your data has already fully traversed.

Our claim is different in kind: the pipeline does not exist.

2. Your input is not our telemetry

There is no analytics event carrying the thing you pasted. There is no “anonymised sample” of payloads for improving the product. There is no error reporter that helpfully attaches the input that caused a parse failure — which is, in practice, one of the most common ways secrets escape from tools that genuinely believed themselves to be private.

If a tool throws, it throws in your tab and stays there.

3. Verifiable, not promised

You should not take this on faith, and you do not have to. Open your browser’s developer tools, switch to the Network tab, and use any tool on the site. Paste a token into the JWT Debugger, decode a certificate, generate a hash. Watch the request list.

You will see the page load its static assets, and then you will see nothing. No XHR, no fetch, no beacon, no WebSocket. That empty list is a stronger assurance than any policy document, because it is an observation you made yourself about the specific bytes you care about.

A privacy policy tells you what a company intends. A network log tells you what a program did.

4. No accounts, no identity, no correlation

There is no sign-up, no session, no profile. This is not a missing feature we intend to add once we monetise. Identity is the join key that turns scattered data into an incident: a paste with no name attached is noise, and the same paste attached to a verified work email is a discovery request waiting to happen.

By having no account system, we hold nothing that could ever link a piece of input to a person — because we hold neither side of that pair.

5. Static delivery, minimal surface

The site is client-side code served as static assets. That removes an entire class of failure that has nothing to do with intent: no application server to be compromised, no API to be enumerated, no injection path into a datastore, no credentials of ours to be stolen and used against you.

The security of a system is bounded by the complexity you can hold in your head. Ours is a bundle and a CDN.

6. Offline is the proof

Load a tool, disconnect from the network, and keep working. The parsing, the conversion, the signing, the verification — all of it continues, because none of it ever depended on us.

This is the cleanest demonstration of the architecture available, and it is also a genuinely useful property. Air-gapped environment, restricted VLAN, aeroplane, a VPN that has opinions: the tool does not care.

7. Privacy is the architecture, not a setting

Every commitment above follows from one decision made once, at the start: do the computation where the data already is. Nothing here is a mode you have to enable, a checkbox you might miss, or a default that could quietly change in a future release. There is no server-side path that a configuration change could accidentally switch on, because we never built one.

That is the whole point of putting it in a manifesto rather than a settings panel. A setting can be changed. An architecture has to be rebuilt.

What “local browser processing” actually means

“Runs in your browser” is a claim worth unpacking, because it is used loosely enough to be meaningless. Concretely, it means the computation happens in one of three places, all of them on your device.

The JavaScript engine in your tab. Parsing a cron expression, converting YAML to JSON, computing subnet boundaries from a CIDR block, formatting JSON — these are ordinary computations over text. They need a parser, not a backend. The only reason such a tool would ever be server-side is that the developer found it easier, not that the problem required it.

The Web Crypto API. Hashing, HMAC, signature generation, signature verification, key derivation, symmetric encryption. The browser exposes hardware-backed, standards-compliant implementations of all of it. When you verify an RS256 signature in the JWT Debugger, the same algorithm your backend runs is running in your tab, against key material that never left it.

WebAssembly, where a native library is the right answer. Some formats — ASN.1 and X.509 among them — have decades of careful parsing logic behind them that is not worth reimplementing badly in JavaScript. Compiling that logic to WASM keeps the correctness and keeps the locality.

None of these three paths has a network step. That is not a coincidence of implementation, it is the selection criterion.

How a credential actually leaks through a utility website

It helps to be specific about the failure mode we are engineering against, because it is rarely dramatic. Here is the ordinary version, and every step of it is boring.

A service is rejecting a token in staging. An engineer needs to see the claims.
They search, land on a decoder, and paste the token. It is a real token — that is the entire point of the exercise, since a synthetic one would not reproduce the bug.
The site POSTs the token to its backend and renders the decoded payload.
The token is now in an access log, an application log, and possibly an error-tracking service, held by a third party under terms nobody in your organisation has read.
The token had a sub, an iss, an aud, maybe an internal user identifier and a scope list. It has now disclosed your identity provider, your service topology, and your authorisation model, independent of whether the signature is still valid.
Nothing happens. There is no alert, because from the network’s point of view an engineer visited a website.

Step 6 is the dangerous one. A leak that produces no signal cannot be responded to, and cannot be measured afterwards. This is why “was the site malicious?” is the wrong question — the log file outlives the intent of whoever created it.

The same walkthrough applies with .env files pasted into converters, private keys pasted into certificate inspectors, and production connection strings pasted into formatters. The shape of the mistake is identical: real data, unremarkable moment, third-party server.

Did You Know? Cross-site data exfiltration is common enough that the browser platform grew a dedicated defence — Content Security Policy’s connect-src directive lets a page declare which origins it may talk to at all, enforced by the browser rather than by the page’s own good behaviour.

Source: MDN, Content Security Policy

The egress checklist: how to evaluate any developer tool

Apply this to us as readily as to anyone else. It takes about ninety seconds.

Open the Network tab before you paste anything. Filter to Fetch/XHR. Then use the tool. Any request carrying your input is a disqualification, whatever the site says.
Try it offline. Load the page, kill the network, use the tool. If it still works, the computation is local. If it spins, it was never yours to begin with.
Read what the page claims, precisely. “We don’t store your data” and “your data never leaves your browser” are not variations on a theme. The first concedes receipt.
Check for an account system. Sign-up flows exist to build a profile. A utility that wants to know who you are wants to correlate something.
Look for a connect-src policy. A site that has restricted its own outbound connections in CSP has made a machine-enforceable commitment, not a prose one.
Ask what happens on error. Error reporters that attach the offending input are the most sympathetic way a private tool becomes a leaky one.

If a tool clears all six, it is a candidate for your egress allowlist. If it clears none, it belongs in the same category as a pastebin.

The honest limits: what local processing does not fix

A manifesto that only lists strengths is marketing. Here is where the boundary actually sits, because knowing it is what makes the guarantee usable.

Your browser is still a computer with other software on it. A malicious or over-permissioned extension with access to page content can read what you type, on our site as on any other. Client-side processing removes the network hop; it does not sandbox you from your own profile. For genuinely high-value material, use a browser profile with no extensions.

The clipboard is shared. Clipboard managers, sync services, and remote-desktop bridges all see what you copy. That is upstream of us entirely.

Screen sharing and recording capture rendered output. A decoded payload on screen during a call is disclosed regardless of where the decoding happened.

Local storage persists what you asked it to. Where a tool keeps preferences or a favourites list, that data lives in your browser’s storage until you clear it. It is local, but it is not ephemeral — on a shared or managed machine, that distinction matters.

A leaked credential is leaked. If a production secret has already been in an email, a ticket, a chat thread, or a shell history, running it through a local tool does not un-expose it. Rotate it.

Our claim is bounded and specific: your input is never transmitted to us, because there is nothing to transmit it to. Everything above that line is your environment, and we would rather say so than let an architectural guarantee do rhetorical work it cannot support.

Doing the work locally: the practical version

The manifesto is only worth anything if the tools are actually good enough to use under pressure. The workflows this changes most:

Token debugging. Decode, sign, and verify with HS, RS, ES, and Ed25519 keys in the JWT Debugger. Real tokens, real key material, no upload — the details of what to validate are in our post on why claims matter for backend security.
Certificate inspection. Read chains, SANs, expiry, and key usage with the Certificate & CSR Decoder instead of pasting a PEM into an online parser.
Basic-auth credentials. Generate bcrypt entries with the htpasswd Generator. This one matters more than most: the input is a password, and a server-side implementation would receive it in plaintext.
Environment files. Convert between .env, JSON, YAML, and shell exports with the .env File Converter. .env files are, almost by definition, the densest concentration of secrets in a repository.
Digests and integrity checks. Compute and compare hashes with the Hash Generator, and handle encoded segments with Base64 Encode / Decode.
Encrypting a value before it moves. Encrypt / Decrypt Text does AES in the tab, so the plaintext exists only on your machine.
The rest of the pipeline. Cron, CIDR, chmod, Kubernetes resources, and Compose conversion all live in the DevOps collection, under the same constraint.

The common thread is that none of these tasks ever needed a server. They were given one because it was convenient for whoever built the tool, and the cost of that convenience was quietly transferred to you.

Conclusion

Privacy-first is not a positioning statement, it is a decision about where computation happens — and once it is made, the marketing claims stop being necessary. We are not asking you to trust that we handle your tokens responsibly. We are pointing out that we never receive them.

In an environment where your organisation’s data-egress policy has become the real arbiter of which tools you are allowed to open, that distinction is the entire product. Every tool runs in your browser. There is no server-side processing, no database, and no account system. Open the Network tab and confirm it.

Frequently Asked Questions

Does KitBoxDev send anything I paste to a server?

No. Every tool runs in your browser, and there is no server-side processing, no database, and no account system to send it to. You can confirm this directly: open your browser’s Network tab, use any tool, and observe that no request carries your input.

How can I verify that a tool really processes data locally?

Two checks, both under a minute. Open DevTools, filter the Network tab to Fetch/XHR, and use the tool — any request containing your input disqualifies it. Then load the page, disconnect from the network, and use the tool again. If it still works, the computation is genuinely local.

Is browser-based cryptography as trustworthy as a server-side implementation?

For the operations these tools perform, yes. The Web Crypto API provides standards-compliant SHA digests, HMAC, RSA, ECDSA, Ed25519, AES-GCM, and PBKDF2 implemented by the browser engine itself. The algorithm is the same one your backend runs; the difference is that the key material never leaves your device.

Can I use a client-side tool with production credentials?

It is far safer than a server-side equivalent, because the credential is never transmitted. But apply normal judgement: your browser extensions, clipboard manager, and screen-sharing session all sit outside any web page’s control. For high-value secrets, use a clean browser profile — and if a credential has already been exposed elsewhere, rotate it regardless.

Why does local processing matter for data-egress policy specifically?

Egress rules and DLP controls exist to catch sensitive data crossing a network boundary. A tool that performs its work entirely in the browser never crosses that boundary, so there is no transfer to detect, log, disclose, or explain. That turns a policy exception request into a non-event.

Does anything get stored in my browser?

Only what a tool needs to remember for you, such as theme preference or a favourites list, and it stays in your browser’s local storage. It is never transmitted. Clearing site data removes it, which is worth doing on shared or managed machines.