Reading somebody else's JSON is a different job from formatting your own
When you wrote the document, you already know the shape. When a colleague pastes you a support export or a webhook payload, the first minute goes on questions a formatter never answers. How deep does this go. Is there one customer record in here or four hundred. Where does the field they are asking about actually live.
This page is built for that first minute. Raw text sits on the left, the rendered document on the right, and the right side arrives folded to two levels so the top of the structure fits on one screen instead of scrolling for a page and a half. Above the reading pane, a bar names the path of whichever line is at the top of your viewport.
Fold it down before you read a single line
Full expansion is the wrong default for a document you have never seen. A 40 KB response opens as roughly 1,400 lines of indentation, and the shape gets lost inside the values.
The depth buttons rewrite the whole fold state in one press. Depth 1 leaves the top level keys and nothing else, which is the fastest way to answer whether you have an envelope with a data array inside or a bare list. Depth 2 is the default and usually shows one full record. Depth 3 suits configuration files where the interesting settings sit three levels in. Any single triangle in the gutter still opens or closes its own block, so you keep the whole file shut and open the one branch you care about.
Folded blocks report what they are hiding rather than going blank. A closed object reads { … 8 keys } and a closed array reads [ … 312 items ], which is often the answer on its own.
The line at the top of the screen has lost its parents
Scroll into the middle of a deep document and every line loses its context. You are looking at "tracking": "AB1234567GB" with no way to tell which of the three order items it belongs to, because the parent key scrolled off the top eleven lines ago.
The dark bar above the reading pane fixes that. It follows the scroll and names the path of whichever line currently sits at the top edge, so you always have $.order.items[1].fulfilment.tracking in view. Click any row and the bar pins to that row instead. Double click it and the path lands on your clipboard, ready for a jq filter or a line of application code.
Why the raw text stays beside the render
The JSON Beautifier on this site argues the opposite case and reformats your document in place with no second pane. For formatting, that is the right call. There is one version of the file and splitting the screen only narrows it.
Reading works differently. The two sides hold different things here. On the left is what actually arrived, single line, escaped, the way the server sent it. On the right is a folded reading of the same bytes. Keeping both in view matters more often than it sounds:
- You paste a fresh response over the old one and watch the right side rebuild, without hunting for an input box that was folded away.
- You trim a broken document down by hand on the left until the parse succeeds, which is the fastest way to isolate the record that is wrong.
- You keep the bytes as they arrived. The reading pane adds indentation, and when somebody asks for the original payload back, the left pane still holds it untouched.
The left pane is a plain textarea rather than a code editor. No autocomplete, no bracket matching, no interference with a paste of half a megabyte. Editing values properly belongs in the JSON Editor, and this page never pretends otherwise.
Numbers come out with the digits they went in with
Most browser based viewers run your text through JSON.parse and re-serialise the result. That step quietly rounds any integer longer than about 15 digits, because JavaScript stores every number as a double.
Load the checkout sample and look at order.reference. The value is 1204598877300112233. A viewer built on parse and stringify hands it back as 1204598877300112000, and nothing on screen warns you.
This page reads the document with its own scanner and keeps the original characters of every number as text. Long references, high precision decimals, 1E+5 and -0.0 all display exactly as written. If you are chasing a Discord or Twitter ID that changed value somewhere in your pipeline, this is one of the few browser tools that will not add to the confusion.
Ctrl+F works here, and that decided how the pane is built
Plenty of JSON viewers draw only the twenty or so rows in your viewport and recycle them as you scroll. The scrolling feels lovely and browser search finds nothing, because the text you are searching for was never in the page.
Rows here are real DOM text, rendered in blocks of 1,200 lines with a button for the next block. Browser find works, text selection works, and so does a screen reader. The trade is honest: past roughly 20,000 lines you will feel the render, and a document that size belongs in jq rather than a browser tab.
There is deliberately no search box on this page. Search across keys and values, with match stepping and a filter for matched branches, already lives in the JSON Navigator. Building a second, weaker version of it here would only split the job in half.
Which of these pages you actually want
Four JSON tools on this site overlap on the surface and answer different questions underneath. Pick by the question, not by the name.
| Your question | The page for it | Why that one |
|---|---|---|
| What is in this document and where | JSON Viewer | Raw text beside a folded reading pane, with a sticky path bar |
Where is the field called x | JSON Navigator | Search over keys and values, arrow key movement, path copying |
| Why will this not parse | JSON Beautifier | Line, column and a plain description of the mistake |
| I need to change a value | JSON Editor | Editing in place instead of a read only pane |
| What changed between these two | JSON Diff | Structural comparison, so reordered keys stop reading as changes |
Where this viewer stops
- The right pane is read only. Folding, selecting and copying a path all work, and typing does nothing. Changes go in the left pane and the render follows.
- Broken input gets a line, a column and a reason, and the last good render stays on screen so you keep your place while you fix the source. No repair is attempted. JSON Fixer is the page that tries.
- One document per load. NDJSON and JSON Lines files hold a separate record on every line, so the whole file fails to parse. Wrap the records in brackets first.
- Comments and trailing commas stay errors. A file carrying either is JSONC or JSON5, and accepting it here would pass something that fails in whatever reads it next.
- The two panes do not scroll together. A folded document has no line for line relationship with its source, so linked scrolling would point at the wrong place most of the time.
- Structure is checked, meaning is not. A missing required field or a string where a number belongs parses cleanly and always will. Generate a schema with JSON to JSON Schema if you need rules enforced.
Everything runs in the tab
Parsing, folding, the path bar and the file open all happen in your browser. There is no upload and no request in the path between your clipboard and the screen. Cut your connection after the page loads and every button still works.
That is not a marketing line, it is the only sane arrangement for this kind of tool. API responses pasted into a viewer routinely carry bearer tokens, connection strings and other people's personal data. None of it should cross a network so you can read it more comfortably.
