JSON Formatter & Validator: Fix Common JSON Mistakes
Reviewed by the OnlineFree.app team · Updated
Key points
- JSON Formatter & Validator pretty-prints, minifies, and validates JSON entirely in the browser, so pasted text never leaves your device.
- Indent options are 2, 4, or 8 spaces or a tab; Minify strips all insignificant whitespace into a single line.
- Errors come with a plain-English message, the line and column, and a caret snippet pointing at the offending character.
- Strict JSON forbids comments, trailing commas, single quotes, and unquoted keys — the four most common parse failures.
- Keep pasted payloads under roughly 5 MB so the browser tab stays responsive while formatting.
What does JSON Formatter & Validator do?
JSON Formatter & Validator is a private, browser-based workbench that pretty-prints, minifies, and validates JSON text without uploading it anywhere. You paste a payload, choose an indent width or Minify, and get formatted output plus a green "Valid JSON" badge — or a red error naming the exact line and column.
We built it as one screen with two zones. The top zone holds the paste area, a live character counter, an indent selector (2 spaces, 4 spaces, 8 spaces or Tab), and a three-way action control: Pretty print, Minify, Validate only, alongside Clear and Paste-from-clipboard buttons. The bottom zone shows the validation strip above a read-only, line-numbered result block with a sticky Copy button.
Everything recalculates as you type, so a fixed brace makes the error banner disappear immediately. To see it working before you trust it with real data, open JSON Formatter & Validator and paste a small object such as {"name":"Ada","active":true}.
One practical limit to know up front: the tool applies a soft cap of roughly 5 MB of pasted text so the tab stays responsive. Beneath the textarea sits a plain line — "Runs 100% in your browser — your JSON never leaves this page." — which is the whole privacy story in one sentence.
The JSON mistakes that break parsers most often
Strict JSON, the format defined in RFC 8259, rejects several things JavaScript object literals happily accept. Comments, a trailing comma after the last property or array item, single-quoted strings, and unquoted property names all fail. The validator flags each one with a plain-English message plus the offending position.
Numbers have their own rules. Leading zeros (007), hexadecimal literals such as 0x1F, NaN, Infinity, and a bare plus sign are not valid JSON numbers. Neither is a real line break inside a string: "notes": "line one\nline two" is fine because \n is an escape, but hitting Enter inside the quotes is not.
Duplicate keys sit in a grey area. Most parsers keep the last value and move on, but RFC 8259 says names within an object SHOULD be unique, and behavior is not guaranteed across languages. If a payload repeats a key, treat it as a bug to fix rather than a formatting quirk to ignore.
The most annoying failure is the one that looks fine. Editors and chat apps sometimes substitute curly quotes for straight ones, and a byte-order mark or non-breaking space pasted from a spreadsheet parses as garbage while rendering as nothing at all.
Why does my JSON look fine but still fail to parse?
Invisible characters are the usual answer. Word processors, CMS fields, and some messaging apps convert straight quotes to curly ones (“ and ” instead of "), which look identical at a glance but are not string delimiters in ECMA-404 or RFC 8259.
When the red banner appears, read the caret snippet rather than the message alone. The tool prints the offending line, the column number, and a short excerpt with a caret under the exact character. Columns count characters, not bytes, so an emoji earlier in the line shifts what your eye expects.
Escape sequences catch people out too. A Windows path written as C:\Users\ana breaks because \U is not a legal escape; write it with doubled backslashes, C:\\Users\\ana, or use forward slashes. A lone backslash at the end of a string is another frequent cause of a confusing parse error.
Pretty print or minify? Picking the right mode
Two spaces is the default indent because it matches most style guides and keeps diffs narrow. Four or eight spaces widen nesting for deeply structured config files, and Tab suits teams that indent with tabs. Indentation never changes keys, values, or their order — only whitespace.
Minify collapses the payload to a single line by removing insignificant whitespace. The byte and character counters next to the result let you see the exact reduction instead of estimating it, which is useful when a payload sits close to a request-size budget.
Validate only is the fastest path when you just need a yes/no verdict, and it is the mode to choose for payloads approaching the ~5 MB soft cap, since rendering a formatted view of a huge document costs far more than parsing it does.
A habit worth keeping: format in the mode you will paste. If the output is going into a request body, copy the minified version; if it is going into a pull request, copy the 2-space version so reviewers can read the change.
Does your JSON leave your browser?
No. Parsing, formatting, and validation run inside your browser using the native JSON parser, so the text you paste is never transmitted anywhere. You can verify that claim in about ten seconds: open your browser's developer tools, switch to the Network tab, paste a payload, and watch for a request. There isn't one.
That matters because JSON payloads are often the most sensitive artifact a developer handles — API keys, bearer tokens, customer records, service-account credentials. Pasting those into a chat assistant or a formatter that POSTs to an API turns a private file into somebody else's log entry. The zero-upload design is the point, not a marketing line.
If you have already pasted secrets somewhere you do not control, rotate the key. Formatting it correctly afterwards does not undo the exposure, and no tool can. For other utilities built on the same no-upload approach, browse the OnlineFree.app free online tools index.
A 6-step check before you ship a JSON payload
Our review routine starts with a bare paste. Step 1: paste the raw text and read the validation strip before touching any option, so you know whether you are fixing a syntax problem or a data problem. Step 2: fix errors top-down using the caret snippet, because one missing closing brace often produces several cascading complaints further down.
Step 3: switch to Pretty print with 2 spaces and skim the structure for keys that should not be there — tokens, debug flags, empty strings, nulls that were meant to be filled in. Step 4: check the root type badge. A payload that should be an array but reports "object" is an early warning that the shape is wrong.
Step 5: switch to Minify and note the byte count so you can compare it against any size budget you care about. Step 6: copy the result with the sticky Copy button, paste it where it belongs, then paste it back into JSON Formatter & Validator one more time. That last re-check takes a second and catches truncated clipboard pastes.
None of this replaces a schema validator or your test suite; it just catches the syntax and shape mistakes before they reach review. For anything that feeds a payment, billing, or safety system, verify the data itself against an authoritative source as well.
Frequently asked questions
Is JSON Formatter & Validator free, and do I need an account?
JSON Formatter & Validator is free to open and use, with no account, sign-up, or email required. You paste your JSON, pick an indent or the Minify action, and read the result. Because processing happens entirely in your browser, there is no server-side usage quota either — the practical ceiling is your tab's memory, not a login.
What is the largest JSON payload JSON Formatter & Validator can handle?
The tool applies a soft cap of roughly 5 MB of pasted text, since very large documents slow the browser tab that renders the formatted output. Payloads well under that size format essentially instantly. If you need to inspect something larger, validate it in chunks or use a local command-line formatter for that one job.
Why does valid-looking JSON produce an error with a line and column number?
Invisible characters are the most common cause. Curly quotes, a byte-order mark, a non-breaking space, or an illegal escape such as a Windows path containing \U all look correct on screen. The error banner names the line and column and shows a caret under the exact character, which reveals the substitute character even when the surrounding text looks identical.
Can I format JSON with tabs instead of two spaces?
Yes. The indent selector offers 2 spaces, 4 spaces, 8 spaces, and Tab, with 2 spaces as the default. The setting applies to Pretty print only. Minify removes all insignificant whitespace regardless of the indent choice, and Validate only leaves your text untouched while reporting whether it parses.
Does JSON Formatter & Validator accept comments or trailing commas?
No. The tool validates strict JSON as specified in RFC 8259, so comments, trailing commas, single-quoted strings, and unquoted property names are all reported as errors. Formats such as JSONC and JSON5 permit some of those, but they are extensions rather than standard JSON. Strip the comments before pasting, or use a parser that explicitly supports JSONC.