If you paste a JSON payload into most online viewers, it takes a round trip through someone’s server. The privacy policy usually says “we don’t store it,” which is reassuring until you realize that “don’t store” is a promise about server behavior, not about what happens to your bytes in the middle. Logs, error trackers, monitoring tools, third-party CDNs: any of them might see a slice of your payload at the moment the server processes it.
Big JSON Viewer is built so that question doesn’t exist. There is no server. Your JSON is parsed, rendered, searched, folded, and copied entirely inside your browser tab. The codebase we deploy is a static bundle, no origin-side processing. This article is about what that’s like to actually build.
What “no server” really means
Our deployment surface is three static assets: the HTML shell, the JS bundle, and the marketing-page metadata. When you load a JSON file via drag-and-drop or paste, the bytes go from your file system to a browser File object to JSON.parse — never crossing a process boundary, never touching fetch, never appearing on any wire.
You can verify this without trusting us. Open browser DevTools, switch to the Network tab, drop a file in. The request log stays empty. No XHR. No fetch. No WebSocket traffic. That’s not a configuration choice; there is literally no code path in the bundle that uploads file contents anywhere.
The one exception, and how we handled it
There is exactly one feature in the app that touches a network: Share. Pressing Share generates a public link to your JSON. That link has to point at bytes somewhere. We had three options:
- Run our own storage. Cheap, easy, and a complete betrayal of the local-only premise.
- Skip the feature. The simplest thing that doesn’t break the architecture. We almost did this.
- Use the user’s own Google Drive via OAuth. The file lives in their Drive folder, under their account, with revocation under their control. Our app never sees the bytes; we just hand it an OAuth token and the file gets PUT directly to Drive’s upload endpoint.
We took option 3. Architecturally, the only thing our code does on Share is: build the JSON, gzip it client-side, POST a resumable upload session to googleapis.com, PUT the gzipped chunks to the upload URL Drive returned, then call Drive’s permissions API to make the file readable to anyone with the link. We never see the file contents, the upload session URL, or the share link before it gets passed back to the UI to display to you.
The privacy callout in the share modal exists because we actually want users to read it before the first share. It says “the file will be uploaded to {your email} — not to our servers,” and that’s literally true: the OAuth flow scopes the upload to your drive.file permission, meaning the app can only see files it specifically created in your Drive. Even the share-management UI we’ll eventually build can only see app-created files, not your unrelated Drive contents.
The recipient side is just as careful
When someone opens a share link, the recipient’s browser fetches the file directly from Drive using a public API key (no OAuth needed, the file is anyone-with-link). The bytes go straight from Drive to the recipient’s browser; we’re a static HTML shell that handles rendering once the bytes have arrived.
There’s no analytics on what JSON people open. We track that a recipient opened a share as a binary event with no payload — that’s how we know the feature is being used. We don’t track which file, who shared it, or anything about the content. The share URL stays in your browser’s URL bar; we never see it.
What this lets users do that other tools don’t
The architecture isn’t free — it costs us some features that need a server. But it also unlocks workflows you can’t do with the alternatives:
- Open production JSON dumps without legal anxiety. If your JSON has customer PII in it, you can paste it into Big JSON Viewer without filing a privacy review. The bytes never leave your machine.
- Use the tool inside an air-gapped network. The bundle is static; once loaded, the app keeps working with no further network access.
- Trust the audit trail. There is no audit trail. We don’t log file contents. If you need “nothing left the machine,” we can give you that guarantee without footnotes.
The price we pay
Local-only forecloses some features that would otherwise be obvious. We can’t do server-side JSON diffing across files; we can’t pre-index large files for instant search across sessions; we can’t run schema validation against an external schema URL on a hostile network; we can’t collaborate in real time on a shared document.
For each of these we’ve had to find a client-side substitute or live without. The diff feature, when it ships, will run in a Web Worker on both files held locally. Schema validation, if it happens, will require the user to paste the schema in — same security model as the JSON. Real-time collaboration probably won’t happen at all; it’s a different product.
Why this trade is the right one
The class of files you reach for “a big JSON viewer” for is dominated by debug exports, production dumps, API responses you’re reverse-engineering, log payloads with stack traces. The shared property of those files is that they probably contain something that doesn’t belong on a stranger’s server. A viewer that requires you to upload them is a viewer you stop reaching for on the things you actually need it for.
So we built one that doesn’t.