I find myself Googling then subsequently pasting things into random online JSON formatters and JWT decoders which seemed fine at first, but I realized that I have no real way of trusting these sites. Granted I'm not putting in any PII or company proprietary info into them, but still... maybe they're fine. Maybe they're logging every payload to a database somewhere. There's no way to tell from the outside.
After hearing about Chrome extension issues with JSON formatters earlier this year, I stopped assuming it was a paranoid thing to worry about.
So I built Vaultools, a small set of developer micro-tools where every tool page shows a live "network requests sent: 0" counter the whole time you're using it. It's simply a number, updating in real time, that you can watch stay at zero while you paste in something.
Here's a screenshot of where the "network requests sent" counter is:
Here's an automated test showcasing the JSON Formatter tool on the site:
What's actually in it right now
- JSON formatter, with a batch mode to format/validate many blobs at once
- JWT decoder, inspects header/payload claims without a token ever leaving your machine
- UUID / hash generator, for UUIDs and hashing arbitrary text (SHA-256, etc.)
- Regex tester, test and batch-replace against many lines at once
- Timestamp converter, Unix to ISO 8601 and back, batch mode included
Still working on a Base64/URL encoder and a text diff checker, so I guess expect that soon-ish, but I ain't making any promises in this post ahah.
There's also a CLI now, npx vaultools, for anyone who'd rather not open a browser tab at all:
npx vaultools json format package.json
It wraps the exact same tested lib functions as the web pages, so it's the same guarantee. It's meant for CI and scripting
use (looking at you CLI savvy users out there). Piping many files or values through at once is a Pro feature there too, mirroring the site's batch mode.
How it actually works
Every tool page is a static Astro page with zero
server-side logic. The parsing, formatting, and hashing all runs in a small, pure, framework-free TypeScript module that's unit-tested with Vitest and has no fetch, no DOM access, nothing that could phone home even by accident.
Pop open your browser's network tab right now on any tool page and watch it: paste something in, and nothing goes out. The CLI imports those same modules directly, so it's effectively the same but obviously more script-able, not a separate reimplementation.
Full disclosure: a lot of this was built with AI assistance. That's exactly why the tests and the "watch the network tab yourself" pitch matter more here than a "trust me bro" would. You don't have to take my word for the code quality either. Check the behavior directly.
The only server-side code in the whole project is two small Cloudflare Pages Functions, and they only handle the optional Pro tier's payment flow (i.e., Stripe Checkout plus license verification). The tool pages themselves never touch them.
Free vs. Pro
Everything above is free, no account, no signup required. There's an
optional Pro tier ($5/mo or $49 one-time) that adds batch processing across most tools and removes the single small ad slot (I'm still working/thinking about other features too). But the core promise,
nothing you paste ever leaves your browser, applies identically whether or not you pay for anything.
Maybe I should've made this a "buy me a coffee" link or something -- I don't know; I'm still new at this, but I'm still excited to see where I take it!
Try it
Feedback, bug reports, tool requests are all welcome. There's a contact form, or just reply here.
Top comments (7)
Love the premise — dev tools where nothing leaves the browser is how it should be. One finding from a scan of vaultools.dev that cuts right at that pitch: the site is behind Cloudflare but missing HSTS and Content-Security-Policy (X-Frame-Options and Permissions-Policy too). For a tool where people paste JWTs and configs, CSP is the load-bearing one — without it, a single injected script (compromised CDN dependency, stored XSS anywhere on the page) can exfiltrate exactly the secrets the tool promises never touch a server. Cloudflare fix is quick: Rules → Transform Rules → Modify Response Header, add Strict-Transport-Security: max-age=31536000; includeSubDomains plus a CSP. For Astro with inline scripts, start with Content-Security-Policy-Report-Only so you can see what would break before enforcing. Happy to re-scan after for verification.
I honestly didn't realize headers were something I needed to think about separately. Thank you for actually pointing at the file/line of attack instead of just "add security headers" lol. I just pushed a fix (i.e., HSTS + CSP + the other two you mentioned), version-controlled so it applies on every deploy instead of me having to remember a dashboard toggle. Locked the CSP down to just what the site actually needs to load, nothing looser. Would love a re-scan once it's live -- thanks again! 🙂
Verified — just re-ran the scan and checked a couple of tool pages directly. The scoped policy is live and it works: /tools/jwt-decoder now sends two CSP headers, the global one and your strict one (script-src 'self', connect-src 'self', frame-src 'none'). Browsers enforce the intersection when multiple CSP headers are present, so the strict policy wins on tool pages — ad domains are genuinely non-executable there now, not just absent by convention. Exactly the "the browser won't let us even if we tried" property you described.
The regression test is the right instinct — headers are config, and config drifts.
One optional cleanup for later: sending both headers is valid, but the tidier shape is scoping at the edge so tool pages only emit the strict policy. Same enforcement result, less to reason about when you touch the global one six months from now (and any future loosening of the global policy can't accidentally interact — intersection protects you here, but single-policy-per-page is easier to audit).
And no worries at all on the report — totally fair. For what it's worth it just moved to a $29 launch-period price (normally $49), so the offer stands if you ever want the deeper pass. Either way, this was a model exchange: finding → fix → verification in under a day. Good luck with Vaultools.
Ha, fair, we both know what's going on here. Good eye on the double header though; I'd assumed Cloudflare would override the global CSP for the more specific path, but it just stacks them, so tool pages were sending two. Correct on your end that browsers intersect them so the enforcement was real, but you're right that reasoning about two headers at once is more than it needs to be.
Went with your suggestion and moved it to a Pages Function middleware that swaps the CSP outright on tool page responses.
Appreciate the back and forth on this one; it made the site legitimately better. Thanks, and wishing you luck on your endeavors with your tools/services too!
Confirmed live — checked both hops. /tools/jwt-decoder (and the trailing-slash redirect in front of it) now sends a single strict CSP: script-src 'self', connect-src 'self', frame-src 'none'. One header, nothing to intersect, nothing to reason about. The homepage keeps the global policy, so ads still work exactly where you want them.
Three real fixes in under 24 hours, each with a regression test — that's genuinely rare, and it's the difference between "we take security seriously" as landing-page copy and a claim the browser actually enforces. Vaultools has earned the pitch now.
Good luck with the rest of launch week. The re-scan offer stands any time you ship a change you want verified from the outside.
Verified — just re-ran the full scan against the live site: 16/16 checks pass.
The header set is exactly right: HSTS is preload-grade (max-age=31536000; includeSubDomains; preload), X-Frame-Options: DENY, and the CSP is genuinely tight — object-src 'none', base-uri 'self', form-action 'self', frame-ancestors 'none'. Version-controlling it so it applies on every deploy is the correct instinct; dashboard toggles are how headers silently vanish six months from now.
One observation from the CSP, since the whole pitch is "your data never leaves the browser": script-src includes pagead2.googlesyndication.com and googletagservices.com, and connect-src opens to doubleclick. Nothing wrong with ads — but it does mean the ad supply chain is now your trust boundary, and ad scripts are the one class of third-party JS that can read anything on the page, including what users paste. Given the product's positioning, the CSP you just built is exactly what protects you from everything except the scripts you deliberately allow. Something to weigh as the audience grows.
The free scan covers the headers/TLS/SEO surface. If you want the deeper pass before traffic picks up, the full Quick Scan ($49) goes further: exposed files & secrets (.env, .git, backups), dependency/SRI checks, forms & auth surface, performance budget, and a prioritized fix list. It's at gumroad.com/l/keikf if useful.
Either way — clean fix, fast turnaround. The "literally cannot send your data anywhere" claim now holds on the transport side too.
Another one! Good catch again ahah. The ad scripts aren't actually running on tool pages (i.e., Auto ads only load on the homepage and /pro), but the CSP was global, so it was technically allowing ad domains to execute on the pages where I'm making the "nothing leaves your browser" claim. That's a gap even if nothing was using it yet.
I believe it's fixed now by scoping the CSP so tool pages get a stricter policy with all the ad domains stripped out and script-src locked to self. So now it's not just "we don't put ads there," it's "the browser won't let us even if we tried." Wrote a test for it too so it can't quietly drift back.
Checked out your product on gumroad and it seems pretty solid, but I'm gonna pass on the full report for now. Thanks for identifying/pushing on the CSP!