How to view large JSON files without freezing your browser

Why big JSON files are awkward in the first place

JSON is a text format with no index. To find the 40,000th object in an array, a parser has to read the 39,999 before it. Standard parsers such as JSON.parse in a browser also expect the whole document as one string, and they build the full object graph in memory before handing it back. That graph is usually bigger than the file on disk, because every key, string and number becomes a separate in-memory value. A 200 MB file can therefore need a good deal more than 200 MB of RAM to parse.

Pretty-printing makes this worse for human readers. A minified file with a million small objects becomes millions of lines once indented, and a text editor or a tree widget that tries to render every line will struggle long before the parser does. So there are really two separate costs: parsing the data, and drawing it. Good tools avoid one or both by loading lazily, by collapsing branches, or by never building the full structure at all.

Step one: check what you actually have

Before opening anything, look at the file from the outside. How big is it, is it one JSON document or one document per line, and does it even end properly? A download that was cut off halfway is the most common reason a "huge" file will not open. These shell commands answer all three questions without loading the file into memory.

ls -lh all-orders.json          # size on disk
head -c 300 all-orders.json      # first 300 bytes: [ or { ? one line or many?
tail -c 200 all-orders.json      # does it end with ] or } ?
jq 'length' all-orders.json      # number of elements if the root is an array

Step two: slice it with jq instead of scrolling

jq is a command-line JSON processor, and for big files it is the tool I reach for first. You describe what you want and it prints only that. The examples below assume the root is an array of order objects, which is the usual shape of an API export. Note that plain jq still reads the whole document into memory before running your filter, so it handles files that are far too big for a browser tab but not files bigger than your RAM.

The point of each command is to turn "a huge file" into "a few lines I can read". Take a sample, pull out one field, or filter down to exactly the records that match your bug. Once the output is small, paste it into any viewer you like.

# First three orders
jq '.[0:3]' all-orders.json

# Only the fields you care about, one compact line per order
jq -c '.[] | {id, status, shipping: .shipping.country}' all-orders.json

# The orders with no shipping address at all (key missing or null)
jq '[.[] | select(.shipping == null)] | length' all-orders.json

# One specific order by ID
jq '.[] | select(.id == "ord_48213")' all-orders.json

Step three: stream when the file will not fit in memory

When a file is a multi-hundred-megabyte export, or larger than the RAM on your machine, you need a streaming approach: read a bit, process it, discard it. jq has a --stream option that emits path and value events instead of building the whole tree, and it works on arbitrary valid JSON. It is powerful but unintuitive, so most people use it only for the one job that matters, which is converting a giant array into one object per line.

That format is called NDJSON or JSON Lines: one complete JSON value per line, separated by newlines. Because every line stands alone, you can use head, grep, wc -l and split on it, and any line-by-line reader can process it with constant memory. Many log pipelines and bulk-export APIs produce it natively. If you control the export, ask for it in that format.

# Convert a big top-level array into NDJSON, one object per line
jq --stream -nc 'fromstream(1|truncate_stream(inputs))' all-orders.json > orders.ndjson

# Now ordinary line tools work
wc -l orders.ndjson
head -n 5 orders.ndjson
grep '"status":"refunded"' orders.ndjson | head

# Cut it into 100,000-line pieces for tools that cannot take the whole thing
split -l 100000 orders.ndjson part_

Streaming parsers in your own code

If the job is repeatable, a small script beats a one-off shell session. Most languages have an incremental JSON parser that yields items from a large array as they are read: ijson in Python, stream-json in Node, Jackson's streaming API in Java, and json.Decoder with Token in Go. They differ in details, but the idea is the same. You walk the stream, keep only the records you need, and write them out or count them, and memory use stays flat whatever the file size.

A realistic use: you have a 3 GB export and want every record where a field is missing. A streaming script reads one object, checks the field, prints the ID if it is missing, and moves on. You end up with a short list of IDs, which is a perfectly ordinary size to open in a viewer, and which you can reproduce next week when someone asks how you found them.

What a browser tab can and cannot do

A browser-based viewer has to download or read the file, parse it, and keep the result in the tab's memory, all while the page stays responsive. How much that handles depends on your device, your browser, how many other tabs are open, and the shape of the data. A million tiny objects behaves differently from ten very long strings. There is no honest single number I can give you, and I would be suspicious of any tool that claims one for every machine. The practical signals are simple: if the tab slows down, scrolling stutters, or the browser offers to kill the page, the file is too big for that tool on that machine.

For files in the tens of megabytes, which covers most API responses and config dumps, a browser viewer is usually fine. For multi-hundred-megabyte files, plan on command-line tools or streaming parsers from the start rather than discovering the limit halfway through. View My JSON is a free web app that parses what you paste or drop locally in your browser, so it follows the same rules: it is a good fit for payloads that fit comfortably in a tab, and the wrong tool for a database-sized dump.

Taking your slice into a viewer

Once jq or a script has reduced the file to a few hundred records, a viewer earns its keep. In View My JSON you can paste the slice or drop the .json file onto the page. Table view lines up the same field across records, which makes the missing shipping address from the earlier example obvious as an empty cell. Tree view lets you open a single order and walk its nested objects. Cards, Table and Tree views, plus Format and Validate, are free, and no account is needed for them.

Pick your sample carefully. The first ten records are rarely representative. Include records that hit the condition you are chasing, records with optional fields present and absent, ones with null values and empty arrays. A sample that only contains well-behaved rows will tell you the data is fine when it is not.

Habits that save time and avoid mistakes

Do not pretty-print a huge file to "make it readable". Indentation can inflate the file considerably and hands your editor millions of lines to render. Keep the minified original and format only the slice you intend to read. Do not treat a sample as proof, either. A sample shows you the schema and lets you form a theory, but only a full pass, by jq, a streaming script or a query on the source system, can tell you that a rare bad value is absent.

Finally, think about the data before you paste it anywhere. Production exports often contain customer names, emails and tokens. Strip or mask what you do not need, or work locally. Save the command you used and the record IDs you found next to your notes. A sanitised failing record makes a perfect test fixture, and it is far easier to attach to a bug report than a 400 MB file.