Format JSON. Fix errors. Understand every key.

No. Parsing, validation, repair, queries, comparison, conversion, schema work and type generation all run in your browser. There is no submit step and no request that carries your document. Files are read locally with the File API.

The five usual causes are a trailing comma before a closing bracket, single quotes instead of double, an unquoted key, a comment, or a smart quote pasted from a document editor. The error panel names which one it found, points at the line and column, and offers the fix. Repair mode will apply it and show you what it changed.

Validating asks whether the document is legal JSON and, if not, where it stops being legal. Formatting re-prints valid JSON with consistent indentation — it cannot fix a broken document. Repairing rewrites a broken document into a valid one and lists every change it made. They are separate modes because they answer separate questions, and because a formatter that silently repairs is a formatter you cannot trust.

Files up to 15MB are read locally. Parsing time depends on the document and the device; tree, table, search and diagnostic output are bounded so one very large result cannot create an unbounded number of rendered rows.

Not as valid input — those are not JSON, and a formatter that accepted them would be teaching the wrong thing. Repair mode handles both, along with single quotes, unquoted keys, code fences, Python literals, JSONP wrappers and NDJSON, and shows you every change.

It is inferred from the one sample you gave it. Optional fields are detected by comparing objects across an array, nullability by seeing a null, and formats by pattern. That is a good starting point and not a specification — check it against a second sample before relying on it, which the interface says on the output.

They are legal in the JSON grammar and `JSON.parse` keeps only the last one, silently. The statistics panel scans the raw text and reports duplicates by path so you know the parsed value is not what you pasted.

Not always. JSON numbers have no precision limit but JavaScript parses them as IEEE-754 doubles, so an integer beyond 2^53 loses exactness. The statistics panel flags any number outside the safe range rather than letting it pass unnoticed.

The common draft-07 keywords: types, required, properties, items, enum, const, the numeric and string bounds, and pattern. `$ref`, `allOf`, `anyOf`, `oneOf`, `not` and the conditional keywords are not evaluated, and the panel names them explicitly when your schema uses one rather than quietly passing.

No. It is pattern matching for the obvious cases — email addresses, JWTs, keys that look like keys, fields named password or authorization. It will miss anything unusual, and it cannot know that an ordinary-looking string is confidential in your context. Treat a clean result as “nothing obvious found”, never as an audit.