JSON-LEE
The JSON tool that never sees your data. Prove it yourself.
I made another round of changes to SafeJSON today.
Not a redesign.
Not a new theme.
Not a big UI change.
Mostly copy, positioning, and how the product explains its privacy model.
That sounds small, but I think it matters more than I expected.
SafeJSON is a browser-based JSON toolkit. It has tools like a JSON formatter, validator, beautifier, viewer, parser, CSV ↔ JSON converter, JSON diff, JWT decoder, JSONPath query, and JSON Schema validator.
The tools themselves are not hard to explain.
The harder part is explaining why this JSON tool should exist when there are already so many JSON tools.
For me, the answer keeps coming back to trust.
“Privacy-first” was too vague
At first, I described SafeJSON as a privacy-first JSON toolkit.
That is not wrong, but it is also not strong enough.
“Privacy-first” is a claim.
And developer tools should not depend too much on claims.
If a tool asks developers to paste API responses, logs, JWTs, webhooks, AI outputs, or backend data into a browser window, the privacy wording needs to be more concrete than that.
Sometimes the pasted JSON is harmless.
Sometimes it contains internal IDs, tokens, credentials, customer data, headers, production logs, or things the developer did not notice were sensitive.
So the real question is not:
“Does this website say it cares about privacy?”
The better question is:
“Can I verify what happens to the content I paste?”
That is the part I wanted SafeJSON to make clearer.
The actual claim should be testable
The wording I moved toward is:
no pasted-content upload
That is much more specific than “privacy-first.”
It does not try to sound bigger than it is.
It does not ask the user to believe a broad marketing promise.
It points to something a developer can check.
Open DevTools → Network.
Paste JSON.
Run the tool.
Check the requests.
The thing to verify is simple:
No request should contain the pasted content.
That is the trust model I want SafeJSON to communicate.
Not “trust this site.”
More like:
“Here is the thing you can test yourself.”
Why this matters for JSON tools
A JSON formatter is boring until the pasted data is not boring.
If you paste sample JSON from a tutorial, it does not matter much.
If you paste a real API response from a production system, it starts to matter.
If you paste a JWT, webhook payload, internal log, or AI output that includes private context, it matters even more.
I do not think every developer will check DevTools every time.
Most probably will not.
But I still think the product should make the verification path obvious.
Because that changes the relationship between the tool and the user.
Instead of saying:
“Please trust that we handle your data safely.”
SafeJSON should say:
“You can check whether your pasted content leaves the browser.”
That feels like a better standard for this category.
What I changed in the product
The recent changes were mostly about making this idea easier to understand.
I tightened the wording around browser-based processing.
I avoided vague security language.
I made the privacy claim more specific.
I tried to make the main difference clearer:
SafeJSON is not trying to win because it has every possible JSON feature.
It is trying to win because it gives developers a simple way to work with JSON without blind trust.
The product is still small.
Current state:
51 users in the last 28 days.
0 paying customers.
Edge extension live.
Chrome extension still pending review.
So this is not a success story.
It is more of a positioning note from building a tiny developer tool.
But this update made one thing clearer for me:
For developer tools, privacy copy should be verifiable.
Not just reassuring.
In November 2025, two of the most popular JSON tools online (jsonformatter.org and codebeautify.org) were caught
leaking user data. Over 80,000 code snippets — including AWS keys, GitHub tokens, and banking details — were publicly
accessible for 5+ years.
Around the same time, the top JSON Formatter Chrome extension (2M+ users) was sold, closed-sourced, and injected with
adware.
I decided to build something that can't leak data — because there's no server to leak from.
---
What SafeJSON does:
- Formats, validates, and beautifies JSON entirely in your browser
- Pro tools: JSON Diff, JWT Decoder, JSONPath, Schema Validator
- Handles 50MB+ JSON files (crashes VS Code)
- Browser extension that auto-detects JSON on any page
The key differentiator: every privacy claim is self-verifiable. Open DevTools → Network tab → use any tool → zero
requests. Not a promise, a check.
Current state (4 weeks since launch):
- 23 pages live (including comparison pages, blog, docs)
- Free core tools + Pro at $5/mo or $39/year
- MIT open source
- First 31 users trickling in, 100% direct traffic
What I'm learning:
- SEO for a new domain is slow. Google sandbox is real.
- Getting the first real users is harder than building the product.
- Bounce rate is brutal when people don't immediately understand the value prop.
Happy to answer questions about the architecture (Next.js, client-side processing, Web Workers), the privacy model, or
anything else.
1 Comment
One thing I'd be careful with:
The interesting question may not be whether the privacy claim is verifiable.
It may be what decision developers are actually making when they choose a JSON tool in the first place.
Those sound similar, but they can lead to very different conclusions about positioning, proof, and what deserves emphasis.
I wouldn't make that call casually from the current signals.