DEV Community: Anirudha Sonwane

What happens when you paste JSON into an online formatter

Anirudha Sonwane — Mon, 05 Oct 2026 10:24:43 +0000

In November 2025, researchers at watchTowr Labs published findings about two popular online formatters — JSONFormatter and CodeBeautify. According to that research, users who used those sites' Save features left shareable copies of their pastes on the services' servers. Both sites also exposed a "Recent Links" page that listed saved items.

watchTowr reported collecting 80,000+ saved JSON submissions — about five years of JSONFormatter history and one year of CodeBeautify data, described as 5GB+ of enriched content. After parsing that dataset, they said it included credentials, keys, configuration data, and personally identifiable information. They also planted canary credentials and later observed those canaries being tested, writing that someone else was already scraping the same sources.

That research is nearly a year old. Site features and exposure can change. This article does not claim either named site leaks data today. It explains the pattern watchTowr described, how to check any tool yourself, and how Tool Reign's JSON tools behave in our own code.

Why "Save" and "Share link" change the risk

Formatting JSON in the browser can stay local. The risk rises when a tool offers Save or a shareable link that stores your paste on a server. According to watchTowr, those shareable URLs followed predictable patterns, and Recent Links pages made saved entries browsable. Once text sits on someone else's server behind a guessable or listable URL, anyone who finds the link can read it — including automated scrapers.

The lesson is general: if a button uploads or persists your paste for later retrieval, treat that paste as public unless you have strong evidence otherwise.

How to check whether a tool sends your data

You can verify any site in a few minutes. Use harmless test data only — never real secrets.

Open the tool in a private/incognito window.
Open DevTools → Network. Enable Preserve log. Filter by Fetch/XHR.
Paste a unique, harmless string (for example a fake key you invent for this test).
Click Format, Beautify, Save, Share, or whatever actions the page offers.
Inspect each request. Look for your test string in the request URL, query string, or request payload. If it appears, that action sent your paste somewhere.

A client-only formatter typically shows no Fetch/XHR that carries your paste when you format or view it. A Save/Share feature that stores content remotely usually posts your text (or an identifier that resolves to it) to an API. Results vary by site and by button — always re-check after UI changes.

Never paste real secrets into any online tool. If you already did, rotate those credentials and keys.

Safer habits

Strip tokens, passwords, and PII before pasting sample JSON.
Prefer editors and formatters that work offline or only in your browser.
Treat every Save / Share / Permalink control as a potential upload until Network proves otherwise.
For API debugging, send only redacted payloads.

What Tool Reign does

What you type, paste, or upload is never sent to our servers.

Our JSON Formatter (including Graph view) formats and renders in your browser, including a local Web Worker for larger documents. Share copies a URL with state in the hash fragment — it is not uploaded to Tool Reign. Draft preferences can stay in your browser's localStorage. You can confirm with the DevTools method above: formatting should not create Fetch/XHR requests that contain your paste.

The API Client is different by design: Direct mode calls the URL you enter from your browser; optional Proxy mode relays the request through a disclosed Tool Reign proxy so you can reach APIs that block browser CORS. That proxy logs only metadata (request id, status class, error code, duration) — never URLs, headers, or bodies. Analytics (GA4 and Clarity) load only after you Accept cookies; tool events carry slugs and similar metadata, not paste contents.

Do not take our word for it — run the Network check on JSON Formatter and the API Client yourself.

Related tools

JSON Formatter & Validator — format, repair, tree/table/graph
JSON graph view — interactive node graph inside the formatter
API Client — Direct or disclosed Proxy mode

Sources

I built an interactive JSON graph viewer that runs entirely in your browser

Anirudha Sonwane — Thu, 01 Oct 2026 06:11:33 +0000

Nested JSON is difficult to understand in a text editor.

Tree views help, but once you're dealing with large API responses or deeply nested objects, following relationships becomes tedious. I wanted something more visual, so I built an interactive Graph View for ToolReign's JSON Formatter.

Instead of reading JSON line by line, you can explore it as a connected node graph.

✨ What it does

Switch from Text, Tree, or Table view to Graph, and your JSON becomes an interactive diagram.

Features

Objects and arrays become connected cards
Strings, numbers, booleans, and null values stay inside their parent node
🔗 Edges connect to the exact field they belong to (not just the center of the card)
Expand or collapse nested branches
Automatic graph layout powered by Dagre
Type-aware rendering
- Strings
- Numbers
- Booleans
- URLs
- Hex colors
Powerful toolbar
- Zoom
- Fit View
- Search with Previous/Next navigation
- Copy subtree
- Replay layout
- Layout settings (Left → Right or Top → Bottom)
Fullscreen mode for huge payloads
Export as PNG or SVG

🔒 Privacy First

Everything runs entirely in your browser.

No uploads
No accounts
No servers processing your JSON
Heavy layouts run in Web Workers for better performance

Your data never leaves your device.

Part of a Bigger JSON Toolkit

The Graph View is built into ToolReign's JSON Formatter, which also includes:

Format & Beautify JSON
Minify JSON
Repair invalid JSON
Auto-correct common syntax errors
JSONPath queries
JSON Schema validation
Generate TypeScript, Go, and Rust models
JSON Compare mode
Shareable URLs
YAML, CSV, and XML support

Try it

Live Demo:

https://toolreign.com/developer/json-formatter/

Paste a messy API response, switch to Graph, and explore the structure visually.

I'd especially love feedback on:

Performance with large arrays
Deeply nested objects
UI/UX improvements
Bugs or edge cases

If you have ideas for new features, let me know. I'm actively improving the tool and would love to hear your feedback.

I built an API client that runs in your browser. Here's how I handled CORS without running an open proxy

Anirudha Sonwane — Mon, 28 Sep 2026 12:34:51 +0000

I built a free API client that runs in the browser as part of Tool Reign. It isn't open source, so there's no code in this post. But the design decisions, especially around the proxy, might help if you're building something similar.

Why a browser-based API client is hard

A browser can send a request to any URL, but it only lets your page read the response if the server allows it. That's CORS, and a lot of APIs don't allow it. Other limits:

Some headers can't be set from a page (Host, Origin, Cookie and a few more)
Set-Cookie can't be read
You only see the response headers the server chose to expose
Detailed timing (DNS, TLS) isn't available

Two modes

Direct: the request goes from your browser to the API. Nothing passes through my server. It works for any API that allows CORS.
Proxy (opt-in): the request goes browser → Tool Reign's server → the API. It shows headers, cookies and timing that the browser hides, and it works for APIs that block browser requests.

Direct is the default. If a request fails with a CORS error, the tool offers to retry through the proxy, with a notice explaining what the proxy sees. Localhost and private-network targets stay Direct-only, on purpose.

The proxy is where the risk is

An endpoint that fetches any URL you give it is the textbook setup for server-side request forgery, and it attracts abuse. This is what I designed it to do: [VERIFY EACH LINE AGAINST YOUR CODE]

Resolve the hostname myself and reject anything private or reserved: loopback, private ranges, link-local (including the cloud metadata address), carrier-grade NAT, multicast, and the IPv6 equivalents, including IPv4-mapped addresses
Connect to the address I validated instead of resolving again, so DNS rebinding can't swap in a private IP
Don't follow redirects automatically; check each hop, and don't carry Authorization or Cookie to a different origin
Cap request size (5 MB), response size (10 MB) and time (30 seconds)
Accept calls only from the site's own origin, with rate limits per client
Store nothing. The app's logs hold a request ID, a status class, an error code and a duration, and no URLs, headers or bodies

The privacy trade-off

The most sensitive things people type into an API client are tokens and keys, and a proxy sees them. That's why it's opt-in, why there's a consent notice the first time, and why the advice is not to use production credentials through it. If you don't want to trust a proxy at all, Direct mode never touches my server.

I'd rather say that plainly than call it "private" and hope nobody checks. Open the Network tab and watch: in Direct mode your request goes to the API you entered (plus analytics requests if you accepted the banner).

Three things that broke while deploying

My zip file. I built the archive on Windows with PowerShell's Compress-Archive. It wrote paths with backslashes, so the Linux host saw files literally named like "src\server.js" and crashed with "cannot find module." A tar-built zip fixed it.
The health check. The hosting platform probes the app to check it's alive. My origin check rejected those probes, so the app stayed marked unhealthy. Health routes need to be exempt.
DNS. At some point during setup, my root domain's A record turned into a "Parked" placeholder, and visitors landed on my registrar's parked page. I never pinned down which step caused it. Check your DNS after every domain change.

What's in the tool

Collections, environments with variables, request history, params, headers, body and auth, plus response body, headers, cookies and timing, code snippets, and import, backup and restore.

Try it: [https://toolreign.com/developer/api-client/]

I'd like to know what's missing for you, and I'm happy to answer architecture questions in the comments.

[Boost]

Anirudha Sonwane — Wed, 08 Jul 2026 05:04:32 +0000

Anirudha Sonwane

Jun 26

I built a free online toolbox with 350+ tools — here's the tech stack and what I learne8

#ai #nextjs #webdev #programming

4 min read

I built a free online toolbox with 350+ tools — here's the tech stack and what I learne8

Anirudha Sonwane — Fri, 26 Jun 2026 06:45:15 +0000

Every small task used to mean a new tab. JSON formatter on one site, GST calculator on another, PDF merger somewhere that wanted my email before it would merge two pages. Ads everywhere, slow UIs, and that low-grade worry about uploading a payslip or invoice to a server I do not control. I got tired of juggling twenty bookmarks for work that should take thirty seconds — so I started building one place for all of it.

What ToolReign is

ToolReign is a free online toolbox: 280+ utilities across 15 categories, all running in your browser. Developer tools (JSON formatter, JWT decoder, API client), text utilities, SEO helpers, PDF and image tools, spreadsheets, and a finance section I built with India in mind — GST with CGST/SGST/IGST splits, EMI and SIP calculators, HRA exemption, gratuity, income tax estimates, and more.

The idea is straightforward: open a tool, do the work, leave. No signup wall, no file uploads to a backend, no account to manage. I am Anirudha Sonwane, a Senior Software Engineer in Pune. ToolReign is a side project I build around my day job — not a pitch deck, just something I wished existed.

The tech stack decisions

Next.js 14 App Router and static export

Each tool lives at its own route under src/app/{category}/{tool-slug}/. That maps cleanly to SEO: one URL, one search intent, one page of metadata. The site exports statically (output: 'export'), so production deployment is uploading an out/ folder to static hosting — no Node server to babysit.

The App Router made this scale. Add a page component, register the slug in tool-registry.json, and the sitemap, category hubs, and search index pick it up automatically. At 260+ tools, hand-maintaining URLs would have broken within a month.

100% client-side — the decision that shaped everything

This was the core architectural bet, and it is also the privacy story: your data never leaves the browser. Finance calculators are plain TypeScript math with useMemo. PDF merge and split use pdf-lib and pdfjs-dist in-tab. Images go through the Canvas API. Audio through the Web Audio API.

The engineering is harder than the marketing. A five-file PDF merge on a mid-range phone can freeze the main thread if you are careless. I had to think about memory when combining multi-megabyte documents, show progress where it matters, and avoid loading entire files when a page-range operation would do. Getting "merge these PDFs" to feel instant without a server was more interesting than wiring another REST endpoint.

The supporting cast

Tailwind CSS and next-themes for light, dark, and system mode — calculators get used late at night more than I expected.
Recharts for finance visualisations: EMI principal-vs-interest donuts, SIP growth curves.
DOMPurify anywhere user-adjacent HTML might render — small surface area, non-negotiable.
Security headers in next.config.js — CSP, HSTS, X-Frame-Options, a tight Permissions-Policy. Static sites still get scanned.
PWA via next-pwa so repeat visitors can install the toolbox like an app.

One scaling problem: metadata without drift

Early on I realised I could not hand-write Open Graph tags for hundreds of tools. Everything funnels through a shared helper:

// src/lib/seo.ts (simplified)
export function buildMetadata({ title, description, path }: {
  title: string
  description: string
  path: string
}): Metadata {
  const canonical = `${SITE.url}${path}`.replace(/([^/])$/, '$1/')
  return {
    title: { default: `${title} | ${SITE.name}`, template: `%s | ${SITE.name}` },
    description,
    keywords: extractKeywords(title, description),
    openGraph: { type: 'website', url: canonical, title, description, locale: 'en_IN' },
    twitter: { card: 'summary_large_image', title, description },
    alternates: { canonical },
  }
}

Each tool page calls buildMetadata() once. Canonical URLs, Twitter cards, and en_IN locale stay consistent. The sitemap reads from the same tool-registry.json, so search indexing and on-site navigation never disagree about what exists.

What surprised me

SEO is half the product. I assumed I would spend ninety percent of my time on calculator logic. Reality: JSON-LD per tool (WebApplication, FAQ schema, HowTo steps), breadcrumb markup, related-tool links, synonym keywords for long-tail queries, collapsible formula explainers on finance pages. Google's AI overviews love "how is EMI calculated?" — a tool site competes on clarity as much as code.

India-specific finance tools punched above their weight. Global EMI calculators are everywhere. Adding GST split logic, HRA exemption rules, and lakh/crore formatting with en-IN locale matched how people actually search here. Locale is not polish — it is a product decision.

Client-side PWAs are more capable than I assumed. Installable shell, offline-friendly caching, no account — it fits the "I just need to convert this PDF" use case better than a bloated web app.

What I would do differently: invest in a stricter component scaffold earlier — shared input toolbars, validation helpers, result placeholders, WhatsApp share buttons, formula explainers — before the finance silo grew past twenty calculators. Copy-paste refactors across similar tools cost more time than the shared abstractions saved later.

What's next

I am continuing down the long tail: more text and developer utilities, deeper finance coverage, and better mobile UX on canvas-heavy tools like handwriting generators. AdSense is on the horizon, but the constraint stays the same — do not interrupt the work surface.

If you try a tool and something feels off, I genuinely want to hear it. Comment here or use the contact form on the site. Broken on Safari? Confusing GST inclusive vs exclusive? Tell me.

Closing

ToolReign started as "one bookmark instead of twenty" and turned into a lesson in static SEO at scale, in-browser media processing, and building for a specific audience without locking everyone else out. It is a side project built after hours in Pune, alongside my work at Giant Leap Systems.

Happy to answer questions about the stack, static export tradeoffs, or how to structure a registry when your tool count stops being cute.

Check it out at toolreign.com — completely free, no account needed.

🚀 Tool Reign is live on Product Hunt today!

If you found this useful, your support means everything.

👉 https://www.producthunt.com/products/tool-reign