Start from the position in the error
Parsers usually report a line and column (position / line / column), and that is the most valuable information you get: narrow to one line, then look at what is missing. Two caveats. First, many parsers report where the anomaly was noticed, while the real mistake sits a line earlier — a missing comma or quote often only surfaces on the next line. Second, if the payload arrives minified on a single line, the line number is useless, so format it first. Formatting also exposes structural mistakes, such as an extra array level that should not be there.
The five most common mistakes
One, trailing commas: {"a": 1,} is invalid — JSON is far stricter than JavaScript. Two, single quotes: keys and strings must use double quotes, so 'a': 'b' always fails. Three, unquoted keys: {a: 1} is JavaScript, but JSON requires quotes around every key. Four, comments: the standard allows neither // nor /* */ — use JSON5, or switch the file to YAML. Five, escaping: a double quote inside a string must be \", a backslash becomes \\, and a Windows path written as C:\Users surprises you. These five cover the overwhelming majority of errors, and checking them in order usually takes a minute.
Chinese text and invisible characters
Chinese itself is fine — UTF-8 supports it fully — but three invisible things confuse parsers. First, a BOM (a stray \uFEFF at the start), common in files exported by some editors and spreadsheet tools; delete it. Second, full-width quotes and commas (“ ” ，), which sneak in when JSON is copied from chat apps or documents and are nearly impossible to spot by eye. Third, zero-width characters (\u200B) and non-breaking spaces (\u00A0), which make identical-looking keys fail to match. The check is direct: paste the suspect fragment somewhere that shows character codes, or strip invisible characters first.
Special values and precision
JSON accepts only null, booleans, numbers, strings, arrays and objects, so NaN, Infinity and undefined are all invalid — express them as null or strings such as "NaN" with an agreed convention. There is no date type either; in practice use ISO 8601 strings (2026-09-24T10:00:00+08:00) to avoid time-zone ambiguity. The trap that bites hardest is big integers: values beyond 2^53 (a 19-digit order number or snowflake ID) lose precision in JavaScript and must travel as strings. Mark the type in the API documentation, or the value is already wrong the moment the front end receives it.
Locating problems in deep nesting
When the structure is deep, deleting beats staring: start at the outermost level, remove a suspicious branch entirely, and see whether validation passes — if it does, the error is inside what you deleted, and a few rounds of bisection find it. You can also fold the formatted text by indentation and check that brackets pair up: a missing closing brace makes the parser complain at the end of the file, pointing at the last line and misleading you. If the shape is arrays inside objects inside arrays, sketch the levels before editing.
A sensible order of work
First format: expand minified content so the structure is visible and line numbers become usable. Second validate: confirm the syntax and strip invisible characters. Third convert: turn valid JSON into YAML, CSV or typed models for the target language (TypeScript interfaces, Go structs, Java records) to avoid transcribing field names by hand. All of it runs in your browser: API responses often carry phone numbers, order IDs and internal fields, and pasting them into an unfamiliar site is riskier than it looks — which is why we never send your data anywhere.
想马上动手：把出错的 JSON 粘进 JSON 格式化与校验 看报错位置与层级；确认无误后用 JSON 转 TypeScript/Go/Java 生成类型，需要给后端同事时用 JSON 与 YAML 互转。Try it now: paste the failing JSON into the JSON formatter and validator to see the error position and structure, generate typed models with JSON to TypeScript/Go/Java, and hand YAML to colleagues via JSON ↔ YAML.
FAQ
How is JSON different from a JavaScript object literal?
JSON is a data format: keys must be double-quoted, trailing commas, comments, undefined and functions are all forbidden. JavaScript literals are far looser, and writing JSON with JS syntax is the single biggest source of errors.
Why did my big integer lose precision?
JavaScript numbers represent integers safely only up to 2^53, so 19-digit IDs get rounded. Have the API return them as strings, or parse with BigInt or a dedicated library.
Can it handle very large JSON?
A few megabytes are fine — parsing and formatting happen in local memory. Much larger files (tens of MB) are better handled with a script, since browsers slow down.