A thoughtful JSON editor with line flags — the tool I always wished existed for handling JSON payloads.

Oscar Hsieh — Mon, 07 Sep 2026 13:43:19 +0000

Most of my JSON work is editing, not reading.

A config file comes in, and I have to change fifteen values scattered through it. Or I get a fixture that needs half its records adjusted before it is useful. So my actual loop is: paste, format, edit, minify, copy back out — and then do it again ten minutes later when something else needs fixing.

The formatting was never the hard part. What kept slowing me down was much dumber than that: after twenty minutes of editing I could no longer remember which lines I had already dealt with. I would scroll up and down re-reading my own changes to check.

So I built JsonSilk around the editing loop instead of around the formatting.

Marking the lines I have touched

This is the feature I started with, and it is still the one I use most.

Click any line number and it gets a flag. The header keeps a count and gives you prev / next to jump between the flagged lines, and a clear to wipe them all. That is the whole feature.

What makes it work is that the flags follow the content, not the line number. If I flag line 40 and then insert ten lines above it, the flag is on line 50 — still on the thing I marked. Storing line numbers would have been much easier to write and would have been wrong within about thirty seconds of real use.

It is a scratch annotation layer for a document I will only have open for ten minutes. Nothing clever, and I did not know how much I wanted it until I had it.

Finding things, in both panes at once

The other half of the loop is finding the values I came to change.

Each pane has its own independent search box, so I can search for different things on each side at the same time. The part that changed how I work is not the box, though — it is that matching line numbers light up in the gutter. In a nine-hundred-line file that turns "where is this key" from scrolling and squinting into a glance.

Both boxes take a regular expression when you tick Regex, which I added once I noticed I was mostly searching for shapes rather than strings: every ISO timestamp, every empty string, every key ending in _id. Two details I had to get right:

Regex and Match case are independent. I nearly made them mutually exclusive, which would have quietly removed "search by pattern, but case-sensitively". With the data {userId, userid, USERID, user_id} and the pattern user.d: plain text finds 0, regex case-insensitive finds 4, regex case-sensitive finds 3.

A half-typed pattern says so. While you are still typing [, the pattern is invalid — and silently returning zero matches looks exactly like "there is nothing here". So the counter reads invalid, the box underlines red, and the reason sits in the tooltip.

The editing loop itself

Format re-indents with two spaces, four spaces or tabs. Minify goes the other way. Optionally every object's keys get sorted recursively, which is what I use when I want to diff two versions of the same config.

The one that removes the most steps is Move to INPUT. You paste a minified blob, format it, and the readable version is now in the right-hand pane — which is read-only. To keep working on it you would have to select, copy, click left, select all, paste. So there is a button that makes the formatted output your new input, cursor at the top. Formatting something already formatted is a no-op, so you can just carry on.

When the JSON is broken mid-edit — which, when you are editing by hand, is most of the time — two things happen that I built for myself:

The error message is a link. Click Line 4, Column 27 and the cursor lands on that character in the input, focused, ready to fix.

The output keeps the last valid result instead of going blank, and says that is what it is doing. Watching my work disappear every time I fat-fingered a bracket was the single most annoying thing about my old loop.

Four ways to look at the same document

Once the editing was comfortable, the thing I wanted next was different ways to see the document. There are four views and they share one search box, so a pattern you wrote while reading the raw JSON keeps working when you switch.

Text is the formatted JSON.

Tree collapses and expands. When you search, branches that have matches inside them get marked rather than auto-expanded — so the shape of the document does not jump around while you type.

Table lays an array of objects out as rows and columns. It is the same projection the CSV export uses, so what you see is what you would save. It loads two thousand rows at a time with the remaining count written on the button, and searching still covers every row, loaded or not.

Mind map draws the document as cards joined by labelled lines: one card per object or array, one row per field, a line out to every nested object with its key on it. It answers a different question from the tree — not "what is inside this branch" but "how is this document shaped". Scroll to move, Ctrl+scroll to zoom, drag the empty canvas to pan, press 0 to fit.

I wrote the mind map myself rather than pulling in a graph library. The layout is two iterative passes, no recursion, and the cards are ordinary HTML absolutely positioned over an SVG layer that draws the edges — which means the values stay selectable text in the same colours the other views use.

That paid off in a way I did not plan. Because the cards are real elements, I could put content-visibility: auto on each one with the exact height the layout had already computed, so cards outside the viewport are skipped entirely. A 3,000-row document draws in 107 ms in the mind map against 267 ms in the tree — the mind map ended up being the faster of the two, which still surprises me.

You can also save the map as SVG or PNG. That one had a trap in it: the obvious approach is to screenshot the DOM, and that produces a wrong image, silently — content-visibility: auto means the off-screen cards have never been laid out or painted, so anything reading the DOM gets a pile of empty boxes and no error. The export re-draws from the layout data instead, so it comes out complete regardless of what is scrolled into view.

Colours I can look at all afternoon

This is not a technical feature but it is the thing I spent the most fiddly time on.

Nothing in the interface is pure white or pure black. The code surface is an off-white #F6F9F4 and the text on it is #232922 — near-black, not #000. The page around it is a muted sage. The dark theme is a deep green #12211D rather than black, for the same reason in the other direction.

The syntax colours are deliberately low-saturation too: keys, strings, numbers and booleans are distinguishable at a glance without any of them shouting. And the same four colours are used in all four views, so a string looks like a string whether you are in the text, tree, table or mind map.

The JSON text also has its own size control in the header, separate from browser zoom, so the code can get bigger without the rest of the page doing the same.

I have no data to prove any of this reduces eye strain. I only know that I stopped noticing the interface, which is what I was aiming for.

Big files stay editable

I wanted a large fixture to still be something I could type in, not just view.

Parsing and printing run in a Web Worker, so the main thread stays free. Only the rows on screen exist in the DOM — the document height is faked with a spacer — so redrawing a 60 MB document costs about the same as a 60 KB one. The re-format delay also grows with document size, so it never fights your typing on a big file.

I have tested to 80 MB and 7.5 million lines. Somewhere between 80 and 100 MB the tab runs out of memory and crashes; peak memory is roughly eight times the file size, which is a browser ceiling rather than something better code fixes.

The tree and table views are more expensive than text — about 1.2 seconds per MB against 0.11 — because they build a second projection and move it back across the worker boundary. So past a few megabytes the tool gives you an estimate in seconds and lets you decide, rather than freezing and hoping.

One thing I found on the way

I did not set out to write a parser. I was going to use JSON.parse like anyone would, and I started there.

Then I noticed a twenty-digit ID coming back as 12345678901234567000. JSON.parse → operate → JSON.stringify is lossy: 1e400 becomes null, -0 becomes 0, and long decimals get rounded. For a tool whose entire job is to show you your own data and hand it back, that was not acceptable.

So every scalar keeps its original literal text, and the printer writes that text back out. Nothing is ever converted to a JavaScript number and back. The YAML, CSV and XML exports read the same raw field, so they are not lossy either.

Writing a JSON parser is not clever — it is a known, bounded problem. It is just work that has to happen up front, because retrofitting it means rewriting the whole pipeline. The unexpected payoff was error messages: since I am walking the text myself, I know exactly where I stopped and what I expected, so a trailing comma can say trailing comma instead of unexpected token.

What it does not do

No server, so no saved documents and no sharing links. No JSON Schema validation. No diff view — which is the one I most expect to want next. The table only understands arrays of objects, because that is the shape that flattens honestly.

Try it

jsonsilk.com — no account, no upload. There is no server; it is a static page, and nothing you paste leaves the tab.

Every feature above exists because the loop I described at the top was two steps longer than it should have been. If something in your JSON workflow is like that, I would like to hear about it.

DEV Community: Oscar Hsieh