About

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 and column structures 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 can run 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.

This isn't just a privacy marketing angle. It has real practical consequences:

You can use it with sensitive data. Paste a log file that contains customer emails. Format a SQL query from your production database. Decode a JWT from a live session. None of it goes anywhere.
It works offline. Once the page has loaded, everything runs locally. No internet connection required for the actual processing.
You can verify it yourself. Open DevTools, go to the Network tab, use any tool. Watch for outgoing requests. You'll find none during processing. That's the promise, and it's verifiable.
It's faster. No round-trip to a server means results are instant. There's no spinner.

We built a Privacy Verifier specifically because we wanted developers to be able to confirm this for themselves. Trust, but verify — especially for tools you're using with sensitive data.

What We've Built So Far

🛡️

Log Sanitizer

Strip PII and API keys from logs before sharing with anyone.

🗄️

SQL Formatter

Make ORM-generated SQL readable. Your schema never leaves your browser.

🔑

JWT Decoder

Inspect JWT payloads and expiry without sharing your secret key.

↔️

Text Diff

Compare two blocks of text and see exactly what changed.

🐍

Python Cleaner

Remove hardcoded secrets from Python scripts before sharing.

✅

Privacy Verifier

Prove for yourself that our tools make zero network requests.

⚖️

Bates Stamper

Add Bates numbers to PDF documents for legal discovery — fully local.

We're also building out a library of practical guides around the same theme — the security and compliance 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 to your database. 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 to establish better habits around data hygiene without a complex process change. Adding a bookmark to ResourceCentral's 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.

We're also not trying to be everything. There are categories of developer tool — IDEs, CI/CD pipelines, monitoring platforms — where a server-side architecture genuinely makes sense. We focus on the tools where it doesn't.

Get in Touch