Why We Built
ResourceCentral
The story behind a free toolkit for developers who'd rather not trust their data to a stranger's server.
The Problem We Kept Running Into
Every developer has been there. It's late. There's a bug. You grab the error log and Google "log sanitizer" or "SQL formatter" or "JWT decoder." You click the first result, paste your data in, get your answer, and move on.
What you probably didn't think about: that site just received your log file. With your customer emails in it. And your internal IP addresses. And possibly an API key someone accidentally let slip into the error output. It's sitting on a server you know nothing about, run by a company you've never heard of, with a privacy policy you didn't read.
We ran into this constantly — not just personally, but in engineering teams we were part of. Developers sharing sanitised-but-not-really logs with ChatGPT. JWTs pasted into jwt.io without thinking. SQL queries with real table names uploaded to formatter tools. All small decisions made under pressure, all adding up to a data handling posture that would make a compliance officer wince.
The frustrating thing was that none of these tools actually need a server. Log sanitisation is regex. SQL formatting is a parser. JWT decoding is Base64. All of it runs in your browser, on your CPU, with zero data leaving your machine. The server architecture of most online developer tools is a choice, not a necessity — and it's often the wrong choice.
The Client-Side Principle
ResourceCentral is built around a single constraint: if a tool doesn't need a server, it doesn't use one.
Paste a log containing customer emails. Format a production SQL query. Decode a live JWT. None of it goes anywhere.
Once the page loads, everything runs locally. No internet connection required for processing.
Open DevTools → Network tab → use any tool. Watch for outgoing requests. You'll find none during processing.
No round-trip to a server means no spinner. Results appear as you type.
We built a Privacy Verifier specifically so developers can confirm this for themselves. Trust, but verify — especially for tools you're using with sensitive data.
What We've Built
We're also building a library of practical security guides — the compliance and data hygiene angles of everyday developer workflows that don't get talked about enough. Log handling under GDPR. The risks of online JWT debuggers. What your ORM is actually sending. Practical, specific, written for developers rather than compliance teams.
Who This Is For
Primarily developers working on software that handles other people's data — which is most software. If your application logs anything that could identify a user, if you work in a regulated industry, if your team uses AI assistants for debugging, or if you've ever pasted something into an online tool and then thought "actually, should I have done that?" — this site is for you.
It's also for teams that want better habits around data hygiene without a complex process change. Adding a bookmark to the Log Sanitizer and telling your team "before pasting any log into anything, run it through this first" is a one-sentence policy change that closes a real category of risk.
What We're Not
We're not a security company. We don't offer compliance consulting, auditing, or certifications. The tools we build are practical utilities — good hygiene aids rather than formal compliance infrastructure. For HIPAA, SOC 2, or GDPR compliance programmes, you need a proper compliance officer and legal counsel, not a free browser tool.
Get in Touch
If there's a tool you think should exist here, a bug you've found, or something you think we've got wrong — we'd genuinely like to hear it. Contact us here, or use the feedback widget at the bottom of any page.