DEV Community: Jon Muller

The people spoke. We listened. You can now copy JSON from fknjsn.

Jon Muller — Wed, 11 Feb 2026 23:38:07 +0000

When I launched fknjsn.com — a local-first JSON comparison tool with no backend, no tracking, and a name your mum wouldn't approve of — I expected maybe twelve people to use it. Mostly me. Possibly my future self debugging the same API at 2am.

Instead, something unexpected happened. People from 15 countries started showing up.

Australia. The United States. The Netherlands. India. The UK. Poland. Germany. Spain. Pakistan. Guatemala. Hong Kong. Romania. Italy. Singapore. Saudi Arabia.

A truly global coalition of developers who are tired of pasting secrets into online formatters and hoping for the best.

And they all wanted the same thing.

"Let me copy the damn JSON"

Fair enough.

You could paste JSON in. You could format it. You could filter it. You could compare two payloads side by side. You could do all of this without a single byte leaving your browser. But when you wanted to actually take the result with you? You were selecting text like an animal.

Developers from across four continents were independently arriving at the same frustration, which honestly felt like a UN resolution against bad clipboard UX.

What's new

You can now copy filtered and formatted JSON with one click. That's it. That's the feature.

Filter a nested payload down to the three keys you care about → copy
Format some minified nightmare into something readable → copy
Compare two responses, find the diff, grab the clean version → copy

It respects whatever state your JSON is in. If you've filtered it, you get the filtered result. If you've formatted it, you get the formatted output. Not the original. Not some re-serialized approximation. What you see is what you copy.

paste → format → filter → copy → done → go outside

Revolutionary stuff. Also known as "finishing the job."

Still no backend

Same architecture as before. Your JSON never leaves your browser. No server. No database. No shareable URLs that attackers can scrape. No save feature that quietly publishes your AWS credentials to a guessable endpoint for five years.

Just localStorage, a copy button, and the basic respect of not uploading your data to someone else's computer.

Try it

fknjsn.com — paste, format, filter, copy. Everything stays local.

The source is still a single HTML file. View source still works. The trust model is still "don't trust me, verify it yourself."

Now with 100% more clipboard support, by popular international demand.

The name is pronounced exactly how you think it is. And apparently, developers in 15 countries all think the same thing.

Why your JSON formatter shouldn't have a backend

Jon Muller — Wed, 14 Jan 2026 22:14:29 +0000

Last month, security researchers found that JSONFormatter and CodeBeautify — two of the most popular online JSON tools — had been leaking saved data for years. Five years of JSONFormatter saves. One year of CodeBeautify. Over 80,000 files containing passwords, API keys, AWS credentials, Active Directory secrets. Governments, banks, telecoms, healthcare.

The "save" feature on these sites creates shareable URLs with predictable patterns. Attackers were actively scraping them. Researchers uploaded fake AWS keys and watched them get tested within 48 hours.

This isn't a bug. It's architecture. Bad architecture, but architecture.

The problem with "save and share"

When you paste JSON into an online formatter and hit save, that data has to go somewhere. Usually a database. Usually with a URL you can share.

That's convenient. It's also a liability.

https://jsonformatter.org/{id}
https://codebeautify.org/{formatter-type}/{id}

These URLs are guessable. Scrapable. And apparently, nobody was checking what people were pasting before storing it forever on a public endpoint. Oops.

Local-first as a security decision

I built fknjsn.com last year because I needed to compare JSON payloads side-by-side. API responses, config diffs, before/after debugging. The usual.

I made a deliberate choice: no backend. Everything lives in localStorage.

// that's it. that's the persistence layer.
localStorage.setItem('json-rows', JSON.stringify(state))

Your data never leaves your browser. There's no server to breach, no database to scrape, no shareable URLs to guess. When you close the tab, your JSON is still there. When you clear your browser data, it's gone. You control the lifecycle.

Revolutionary stuff. Also known as "not being stupid."

What you give up

No sharing. If you want to send JSON to a colleague, you copy-paste it like an animal. There's no "generate link" button.

For my use case, that's fine. I'm usually comparing things I don't want to share anyway — API responses with auth tokens, config files with secrets, debug output with customer data.

If you need collaboration, this isn't the tool. But if you're pasting sensitive data into a formatter, maybe ask yourself: do I actually need that link? Or do I just click buttons because they're there?

The localStorage tradeoff

localStorage isn't encrypted. Anyone with access to your machine can read it. That's a real consideration.

But compare the threat models:

Online formatter with save feature:

Data stored on third-party server
Predictable URLs enable scraping
You trust their security practices (lol)
Data persists indefinitely unless manually deleted
Breach affects all users at once

localStorage:

Data stored on your machine
No network exposure
You trust your own device security
Data cleared with browser data
Breach requires physical/remote access to your specific machine

For most developers pasting API responses, the second model is dramatically safer. Unless you're worried about your cat.

Implementation is trivial

The entire persistence layer is a debounced write on state change:

watch(rows, () => {
  clearTimeout(saveTimeout)
  saveTimeout = setTimeout(() => {
    localStorage.setItem('json-rows', JSON.stringify({
      rows: rows.value,
      selectedRowId: selectedRowId.value
    }))
  }, 500)
}, { deep: true })

On load, read it back:

onMounted(() => {
  const saved = localStorage.getItem('json-rows')
  if (saved) {
    const state = JSON.parse(saved)
    rows.value = state.rows
    selectedRowId.value = state.selectedRowId
  }
})

No auth. No API. No database migrations. No GDPR compliance headaches because you're not collecting anything. Turns out the easiest way to secure user data is to not have it.

When to use what

Use an online formatter when:

You're working with public, non-sensitive data
You genuinely need to share a link
You trust the service and have reviewed their data practices

Use a local-first tool when:

You're handling API responses, configs, or debug output
The data might contain secrets, tokens, or PII
You don't need collaboration
You'd rather not think about whether some random site is storing your pastes forever

Try it

fknjsn.com — paste JSON, compare side-by-side, filter/search within each block. Everything stays in your browser.

The whole thing is a single HTML file. View source if you want to verify there's no tracking, no analytics, no sneaky POST requests. There's nothing to sneak.

The name is pronounced exactly how you think it is.

I built a JSON diff tool in a single HTML file (no build step)

Jon Muller — Wed, 07 Jan 2026 03:49:31 +0000

I built a JSON diff tool in a single HTML file (no build step)

I kept needing to compare JSON payloads side-by-side. API response vs expected. Before vs after. Prod vs staging. Every time, I'd paste into some random online tool, squint at it, then do it again five minutes later.

So I built fknjsn.com — a local-first JSON comparison tool. The whole thing is one HTML file with no build step.

The stack (or lack thereof)

Vue 3 via CDN (global build)
vue-json-pretty via CDN for the tree rendering
localStorage for persistence
That's it

No webpack. No vite. No node_modules. No package.json. Just a single index.html you could email to someone.

Why no build step?

Mostly stubbornness. I wanted to see how far I could get before reaching for tooling.

Turns out: pretty far. The setup is just two script tags and a destructure:

<script src="https://unpkg.com/vue@3.4.21/dist/vue.global.prod.js"></script>
<script src="https://unpkg.com/vue-json-pretty@2.4.0/lib/vue-json-pretty.js"></script>

<script>
const { createApp, ref, computed, watch, onMounted, nextTick } = Vue;

// ... the rest is just Vue
</script>

Global builds aren't fashionable, but they work. No bundler required, no import maps to configure, just script tags like it's 2014 — except now you get a reactive framework.

The interesting bits

Paste-anywhere UX: The app listens for paste events globally, but ignores them when you're focused on an input. So you can paste JSON anywhere on the page and it lands in the selected row.

window.addEventListener('paste', (e) => {
  const tag = document.activeElement?.tagName?.toLowerCase()
  if (tag === 'input' || tag === 'textarea') return

  try {
    const json = JSON.parse(e.clipboardData.getData('text'))
    addJsonToSelectedRow(json)
  } catch {
    // not valid JSON, ignore
  }
})

Recursive search: Each JSON block has its own search input. The filter walks the tree and keeps parent nodes if any descendant matches. The actual implementation is more verbose, but conceptually:

function filterJson(obj, search) {
  if (!search) return obj
  const lower = search.toLowerCase()

  if (Array.isArray(obj)) {
    const filtered = obj
      .map(item => filterJson(item, search))
      .filter(item => item !== undefined)
    return filtered.length ? filtered : undefined
  }

  if (obj && typeof obj === 'object') {
    const result = {}
    for (const [key, value] of Object.entries(obj)) {
      if (key.toLowerCase().includes(lower)) {
        result[key] = value
      } else {
        const filtered = filterJson(value, search)
        if (filtered !== undefined) result[key] = filtered
      }
    }
    return Object.keys(result).length ? result : undefined
  }

  // primitives
  const str = String(obj).toLowerCase()
  return str.includes(lower) ? obj : undefined
}

Debounced persistence: State saves to localStorage, but debounced at 500ms so rapid changes don't hammer storage:

watch(rows, () => {
  clearTimeout(saveTimeout)
  saveTimeout = setTimeout(() => {
    localStorage.setItem('json-rows', JSON.stringify(state))
  }, 500)
}, { deep: true })

What I'd do differently

If this needed to scale (bigger JSON, more features), I'd probably:

Add a web worker for filtering large payloads
Use virtual scrolling for the tree view
Actually add a diff view instead of just side-by-side

But for now it does what I need, and the whole thing fits in my head.

Try it

fknjsn.com

Source is view-source — it's all right there.

The name is pronounced how you think it is.