JSON viewer: open a huge JSON file, JSON Lines or a Jupyter notebook

What it shows

• A collapsible tree. Each row shows a key, its type and a preview: strings and numbers as written, objects and arrays with their size ({} 9 keys, [] 320,000 items). An array or object opens 200 children at a time, with buttons for the next and previous 200, so opening an array of a million items draws 200 rows, not a million.
• The path of the selected value, ready to copy: $.items[42].name. Keys that are not plain identifiers are quoted in brackets, as in $["odd key"][0] or $.headers["content-type"]. This is JSONPath syntax (RFC 9535), and with a variable name in place of the $ it is also JavaScript: data.items[42].name.
• Search of every key and value, ignoring case. It reports the total number of matches and lists the first 1,000 as paths. Click one and the tree opens down to it. A key that matches counts once, and so does a value.
• JSON Lines and NDJSON (.jsonl, .ndjson, and a .json file that turns out to hold one value per line) as a table of records. The columns are the keys found in the records and the # column is the line number in the file. The page counts the records and names every malformed line. A log export with 2 broken lines out of 1,000 shows 998 records and says "lines 137, 802". The records are also browsable and searchable as a tree.
• Jupyter notebooks (.ipynb) as a notebook: Markdown cells rendered, code cells with their In [3]: execution count, and the outputs saved in the file. Those are printed text, results, error tracebacks with the terminal colour codes removed, and PNG, JPEG, GIF and SVG plots. Images attached to Markdown cells are shown. nbviewer can only show a notebook at a public web address; here a private notebook stays on your computer.
• HAR files, the network logs browsers save from their developer tools, open as a tree: $.log.entries[0].request.url and the rest. A HAR file usually contains cookies, session tokens and form data, which is one more reason not to paste it into an online viewer.

How it stays responsive

The file goes to a Web Worker, a background thread. The worker reads it, parses it with the browser's own JSON.parse and keeps the result. The page never receives the whole parsed value; copying a 50 MB object tree between threads would block the page for seconds. It asks for one level of one node at a time (key, type, a short preview and the child count for up to 200 children) and draws only that. Search runs in the worker too, and only the matching paths come back.

The site's automated test builds a 58 MB JSON file of 320,000 records inside headless Chrome and drops it on this page. It then measures every moment the page could not respond. It requires none to last 200 ms or more. On the test server the tree was ready about 0.6 seconds after the drop, and no pause reached 50 ms, the shortest the browser's Long Tasks API reports. A search of every key and value in the file took about 0.3 seconds. In a separate run on the same server, a 202 MB file of 1.1 million records opened in about 2 seconds, also without a pause of 50 ms.

JSON Lines are read as a stream, line by line, without holding the file as one piece of text. The table fills in while the file is still being read.

What it cannot do

• Edit, convert or validate against a schema. It is a viewer. Nothing you open can be changed or saved from here.
• Run code. A notebook's outputs are the ones saved in the file. No kernel runs, so cells cannot be re-run, and a notebook saved without outputs shows none.
• Render HTML, JavaScript or widget outputs. A pandas table's HTML, a Plotly or Bokeh chart, an ipywidgets slider, or anything a cell wrote with display(HTML(...)), is shown as its source text, never rendered or run. When the output also has a plain-text form (pandas always adds one), that is shown first. Images in Markdown that point at a web address are not loaded either; they appear as [image not loaded: https://…], so opening a notebook never tells anyone that you did.
• JSON with comments or trailing commas. VS Code settings, tsconfig.json and JSON5 files are not standard JSON. The page does not guess or repair them. It says where the file stops being JSON and why, for example "at line 3, column 17: there is a trailing comma before a closing bracket", and shows nothing else. The same goes for single-quoted strings, unquoted keys and NaN.
• Huge integers exactly. Numbers are read as JavaScript numbers, which are exact only up to 9,007,199,254,740,991. A 19-digit ID such as 1234567890123456789 shows as 1234567890123456800. If an object repeats a key, only the last value is kept, as in every JSON.parse.
• Files bigger than the tab's memory. A parsed JSON file takes about twice its size in memory, plus the text while it is being parsed. Measured in V8, the JavaScript engine in Chrome and Edge, a 58 MB file of small records took 120 MB once parsed, and 178 MB at the peak while the text and the parsed value both existed; a 202 MB file took 411 MB, with a 613 MB peak. Chrome and Edge also cannot hold a single text longer than 536,870,888 characters, so a .json file over about 512 MB cannot be opened at all. JSON Lines avoid that cap because they are read line by line, but every record still has to fit in memory. Phones run out sooner: a phone browser gives a tab far less memory than a computer does, and it may reload the page instead of showing an error.