Back in my WP Adminify days, a support ticket landed that read simply: "Settings import broken. Nothing works." The user had hand-edited an exported settings file — one trailing comma on line 217 of a 9,000-line JSON blob — and my importer responded with the world's least helpful error: Import failed.
I wrote that error message. That's on me.
It took the two of us 40-odd minutes of back-and-forth to find one comma that a decent formatter would have flagged in half a second. That ticket changed how I think about JSON tooling, and years later it shaped how I built the JSON Formatter on toolz.dev: the error location isn't a nice-to-have. It's the entire product.
This guide covers how to format JSON online, why formatting fails, and the syntax traps that eat everyone's afternoon eventually — including mine.
TL;DR: To format JSON online, paste it into a client-side tool like the toolz.dev JSON Formatter — it pretty-prints instantly, flags syntax errors with line numbers, and never uploads your data. If formatting fails, you almost certainly have a trailing comma, single quotes, or an unquoted key. Use 2-space indentation unless your team says otherwise.
What Does "Formatting JSON" Actually Do?
Formatting — pretty-printing, if you're feeling fancy — adds indentation and line breaks so the structure becomes visible. The data doesn't change by a single bit. It's a presentation transform, nothing more.
This:
{"employees":[{"firstName":"John","lastName":"Doe","department":"Engineering","skills":["JavaScript","Python","Docker"]},{"firstName":"Jane","lastName":"Smith","department":"Design","skills":["Figma","CSS","Illustration"]}],"company":"Acme Corp","founded":2015}
becomes this:
{
"employees": [
{
"firstName": "John",
"lastName": "Doe",
"department": "Engineering",
"skills": ["JavaScript", "Python", "Docker"]
},
{
"firstName": "Jane",
"lastName": "Smith",
"department": "Design",
"skills": ["Figma", "CSS", "Illustration"]
}
],
"company": "Acme Corp",
"founded": 2015
}
Identical data. But only one of them lets you spot at a glance that Jane is in Design.
There's a bonus most people don't think about: formatting is also validation in disguise. A formatter has to parse your document to reformat it, so if the JSON is broken, a good formatter tells you where — which is the actual reason to use one instead of squinting.
How Do You Format JSON Online in Practice?
The whole workflow is about fifteen seconds:
- Copy the JSON from wherever it lives — DevTools Network tab (right-click a request → Copy Response),
curloutput, a log file, a colleague's Slack message. - Open the JSON Formatter. No signup, no login. It loads and you paste.
- Read the output. Valid JSON comes back indented and syntax-highlighted, with collapsible sections for big documents. Invalid JSON gets an error with a line number and a plain-English description.
- Copy or download. One click either way.
That's it. The interesting part isn't the happy path — it's step 3 when things go wrong. So let's go wrong.
Why Is My JSON Not Formatting?
If a formatter refuses your JSON, the document violates the grammar in RFC 8259. In my experience — both from my own debugging and from building the tool people paste their broken JSON into — it's nearly always one of five things.
1. Trailing commas
{
"name": "Alice",
"age": 30,
}
SyntaxError: Unexpected token } in JSON at position 34
JavaScript allows this. JSON never has. Delete the comma after the last item in every object and array:
{
"name": "Alice",
"age": 30
}
This is my support-ticket comma. Respect it.
2. Single quotes
{ 'name': 'Alice' }
The classic Python tell. str(my_dict) produces single-quoted pseudo-JSON; json.dumps(my_dict) produces the real thing. If you're seeing single quotes in something claiming to be JSON, someone printed a dict instead of serializing it — I've done it, you've done it, we'll all do it again.
{ "name": "Alice" }
3. Unescaped backslashes
{ "path": "C:\new\test" }
Looks harmless. But \n is a newline and \t is a tab, so this parses into a path with actual line breaks in it — or fails outright on sequences like \x. Windows paths are the number one victim:
{ "path": "C:\\new\\test" }
4. Mismatched brackets
{
"users": [
{"name": "Alice"},
{"name": "Bob"}
}
Missing ]. Trivial here, brutal in a config nested six levels deep. This is a category of error humans are genuinely bad at finding and parsers find instantly — outsource it.
5. JavaScript values that aren't JSON
{ "value": undefined, "count": NaN }
undefined, NaN, and Infinity are JavaScript, not JSON. JSON.stringify quietly converts NaN to null and drops undefined properties entirely — which means the bug often isn't in the JSON you're looking at, it's upstream in whatever produced it. Use null explicitly and check your serializer.
The formatter catches all five with the line number attached. That last sentence is the whole reason this tool category exists.
Should You Use 2 Spaces, 4 Spaces, or Tabs?
The eternal debate, JSON edition. Here's the honest comparison:
| 2 spaces | 4 spaces | Tabs | |
|---|---|---|---|
| Ecosystem | JavaScript/TypeScript, npm, React | Python, Java, .NET | Go, some legacy code |
| Deep nesting | Stays on screen | Runs off the right edge | Depends on tab width |
| Diff readability | Good | Good | Good until mixed with spaces |
JSON.stringify default arg |
2 (by convention) |
4 |
"\t" |
| My verdict | Default for JSON | Fine if your team's Python-first | Don't, for JSON specifically |
My position, and I'll die on this small hill: 2 spaces for JSON, regardless of what your other code uses. JSON nests deeper than typical source code — API responses four and five levels deep are normal — and 4-space indentation turns them into horizontal scrolling exercises. Even in Python-heavy teams I set JSON to 2 spaces and nobody has ever complained twice.
Whatever you pick, encode it so the debate ends:
# .editorconfig
[*.json]
indent_style = space
indent_size = 2
insert_final_newline = true
The formatter supports both widths, so matching your project's convention is a dropdown, not a discussion.
What About Formatting From the Command Line?
Sometimes the terminal is closer than a browser tab. My actual usage:
# jq — the standard. Install it, learn 10% of it, profit.
curl -s https://api.example.com/users | jq .
# Python — already on basically every machine
curl -s https://api.example.com/users | python -m json.tool
# Node, if you enjoy typing
node -e "console.log(JSON.stringify(JSON.parse(require('fs').readFileSync(0,'utf8')),null,2))" < data.json
Where each wins, honestly:
- jq for anything scripted, repeated, or piped — and for extracting fields (
jq '.data.users[].email') rather than reading whole documents. - The browser tool for one-offs, for anything you want to explore with collapsible sections, and for showing a teammate — you can't screen-share a jq expression to a project manager.
- VS Code (
Shift+Alt+F) for JSON files that live in the repo and are open anyway.
I use all three daily. Anyone who tells you one replaces the others is selling something.
One habit worth stealing: curl -s ... > response.json first, then format the file. When the response turns out to be an HTML error page wearing a Content-Type: application/json costume — happens more than any of us would like — you'll want the original bytes, not your browser's interpretation of them.
Three Formatting Techniques Most People Skip
Sort keys alphabetically. Different serializers emit keys in different orders, which makes diffs of the "same" data look like rewrites. Sorting keys before diffing turns a 300-line diff into the 2 lines that actually changed. This pairs beautifully with the Text Diff tool when comparing staging vs production payloads — a trick that has personally saved me during at least two incidents.
Keep short arrays inline. "colors": ["red", "green", "blue"] on one line reads better than five lines of ceremony. Good formatters do this automatically for arrays of primitives; it's the difference between formatted JSON you can skim and formatted JSON that's technically pretty but 4,000 lines long.
Format the fragment, not the file. For a 15 MB document when you only care about one object: copy that nested object, format it alone, done. Formatting the whole file so you can read 40 lines of it is wasted effort — though if you do need the whole thing, a client-side tool handles it without an upload progress bar, because there's no upload.
And know when not to format: minified JSON in production bundles and API responses should stay minified. Formatting is for eyes, not wires. If you need the opposite direction, the same tool minifies with one click.
Frequently Asked Questions
How do I format JSON online for free?
Paste your JSON into the toolz.dev JSON Formatter — it formats instantly with syntax highlighting and error checking, free, no signup. Processing happens in your browser, so nothing you paste is uploaded anywhere. That last part matters more than the "free" part if the payload contains tokens or user data.
Why is my JSON not formatting correctly?
The document has a syntax error, and the top suspects are trailing commas, single quotes, unquoted keys, unescaped backslashes, and mismatched brackets. A formatter that validates will point at the exact line. If the error makes no sense, check whether you actually have JSON at all — APIs love returning HTML error pages with a JSON content type.
What's the difference between formatting and validating JSON?
Formatting rewrites whitespace for readability; validating checks the document against the RFC 8259 grammar. In practice they're the same operation — a formatter must parse (validate) before it can reformat. That's why "it won't format" and "it's invalid" are the same diagnosis.
Should I use 2 or 4 spaces for JSON indentation?
Use 2 spaces unless your project already standardized on 4. JSON nests deeper than most source code, and 2-space indentation keeps real-world API responses readable without horizontal scrolling. Then lock the choice into .editorconfig so it never comes up in code review again.
Can I format JSON in VS Code without an extension?
Yes — Shift+Alt+F (or Shift+Option+F on Mac) formats any JSON file with the built-in formatter, and "Format on Save" makes it automatic. Note that VS Code's own settings.json is JSONC, which allows comments — don't let that convince you regular JSON does.
Is it safe to paste API responses into online JSON formatters?
Only into client-side ones. Plenty of formatter sites POST your input to a server, which means your API response — tokens, emails, all of it — now exists in someone else's logs. The toolz.dev formatter runs entirely in your browser; verify it yourself by watching the Network tab while you paste.
How do I format a huge JSON file (10 MB+)?
Client-side browser tools handle files in this range fine since there's no upload step — the paste is the slow part. Past 50 MB or so, switch to streaming tools: jq on the command line, or extract just the section you need and format that. Never paste huge files into server-based tools; you're waiting on an upload for no benefit.
How do I minify JSON instead of formatting it?
Same tool, opposite button — the JSON Formatter has a one-click minify mode that strips all whitespace. Minify for production payloads, localStorage, and log pipelines; format for humans. The data is identical either way.
Does formatting JSON change the data?
No — formatting only rewrites whitespace, so the keys, values, and structure stay identical in meaning. A formatted document and its minified version parse to exactly the same object. If your data actually changes, you edited something by hand rather than just formatting.
What is a JSON beautifier?
It's another name for a JSON formatter — a tool that takes minified or messy JSON and adds indentation and line breaks so a human can read it. "Beautify," "pretty-print," and "format" all describe the same operation. The JSON Formatter does it in one paste.
The Fifteen-Second Habit
Formatting JSON is a small skill with outsized returns — most "the API is broken" moments are really "the payload is unreadable" moments, and those dissolve the second the structure becomes visible. Get the paste-format-read loop down to fifteen seconds and a whole category of debugging friction disappears.
The JSON Formatter on toolz.dev is the version of this tool I wanted during that support ticket: instant, precise about errors, and incapable of leaking your data because it never receives it.
Once your JSON is clean, the next step is usually moving it somewhere — into a spreadsheet with the JSON to CSV Converter, back out of one with the CSV to JSON Converter, or into a config pipeline via the YAML Validator. Start with the JSON to CSV guide or go back up to the complete JSON tools guide for the full map.
Related Articles:
