Shadow IT at the browser: free tools and sensitive data.

Security questionnaires ask about approved vendors and SSO. Meanwhile, on a Tuesday afternoon, someone on the payments team is decoding a JWT on a site they found through Google. The token isn't in a ticket. It's in someone else's server logs.

That's shadow IT — work happening outside the controls you thought you had. It's usually not malicious. It's someone trying to finish a task with the first tool that looks free and fast.

Shadow IT isn't always a SaaS invoice.

Classic shadow IT is a team buying Trello with a corporate card. Modern shadow IT is quieter:

• Pasting a customer CSV into a "free online converter"
• Uploading a contract PDF to compress it before email
• Decoding a production JWT to see why an integration failed
• Running HR documents through an image tool that "doesn't store files" (their privacy policy says otherwise)

Blocking categories in the firewall helps until someone tethering a phone or using home Wi‑Fi does the same thing. The failure mode isn't "we forgot to buy software." It's "the approved path was slower than the risky one."

What actually leaves the browser.

Not all "online tools" are the same. Rough taxonomy:

Architecture	Your file / secret	Typical monetization
Server-side processing	Uploaded to their infrastructure	Ads, accounts, upsell
Client-side (real)	Stays on device; JS/WASM does the work	Ads, tips, sometimes honest
"Client-side" (marketing)	Still phones home for fonts, analytics, or "cloud sync"	Data-adjacent business models

You can verify the first case in DevTools: watch the Network tab while you convert a file. If you see a multipart POST to their origin with your payload, that's server-side no matter what the landing page claims.

Even real client-side tools can leak metadata — analytics, CDN font requests, error reporting. That's why "client-side" has three ways to still leak. But metadata leakage and uploading the file itself are different risk classes. Security teams care about both; compliance teams often care most about the upload.

When client-side is the control.

If processing happens entirely in the browser, the vendor never receives the document. That's not marketing — it's architecture. The trade-off is honest too: you're trusting their JavaScript not to exfiltrate (audit the bundle, use tools from sources you can read), and you're trusting the user's machine (malware, shoulder surfing, shared screen recordings).

For many organisations the calculus becomes:

• Block public upload sites — still correct
• Allow vetted client-side tools — either on the public web or internally
• Prefer internal hosting — same static bundle, behind your firewall, no third-party URL in the address bar

That's the niche Tooly for Teams exists for: the same 40-tool static site, licensed for deployment on nginx or S3 inside your network. Not a new SaaS login — a zip file IT can mirror.

Self-hosted static tools.

Self-hosting doesn't magically fix endpoint compromise, but it removes an entire class of vendor risk:

• No third party holding copies of pasted secrets
• No surprise acquisition by an ad-tech company next year
• CSP and network policy you control
• Code you can diff when you update the bundle

The deployment model is boring on purpose: static HTML, CSS, and JavaScript. No Tooly server in the loop. Updates are a new zip once a year if you want them.

If you're an individual, the public site at toolymctoolface.com is free and client-side. If you're a security lead reading incident post-mortems about "someone used a random PDF site," the fix is usually friction and alternatives, not another lecture.

Takeaways.

Blocking without replacement doesn't stop the behaviour — it relocates it. The organisations that win this are the ones where the safe tool is faster than the risky one.