How to format and validate JSON without uploading it

Why it matters where the formatting happens

JSON that needs formatting is rarely harmless sample data. It is usually an API response copied from a log, a webhook payload, or a configuration file, and it can contain customer records, internal hostnames, or access tokens. Many online formatters send what you paste to a server to process it. That is one more copy of the data in a place you do not control.

The socket.help JSON formatter runs in your browser. Parsing, indenting, and minifying happen on your device, and the document is not sent to socket.help when you use the page. You can paste a response, read it, and close the tab without creating a stored copy anywhere else.

Format, validate, or minify in three steps

Formatting adds line breaks and two-space indentation so nested objects and arrays are easy to scan. Minifying does the reverse: it removes whitespace outside strings, which is useful before pasting a body into a request or an environment variable. Both actions validate the document first.

• Open the JSON formatter and paste your document.
• Choose Format JSON for a readable version, or Minify for a single line.
• Copy the result, or fix the syntax error the tool reports and try again.

What validation catches

The formatter accepts standard JSON as described in RFC 8259 and nothing looser. Comments, trailing commas, single-quoted strings, unquoted keys, and values such as NaN are rejected. These are the most common reasons a file that looks fine in an editor fails in a parser: JavaScript object literals, JSON5, and many configuration formats allow them, but JSON does not.

The error comes from your browser’s own JSON parser, so the wording differs between browsers. Most report a character position, and some add a line and column. A trailing comma usually shows up as an unexpected character just before a closing brace, and a comment as unexpected text after the end of the document.

Validation here means the text is syntactically valid JSON. It does not check the document against a JSON Schema, an OpenAPI definition, or the fields your application expects. A well-formed response with a missing field will format without complaint.

Two other problems look like syntax errors but are not caused by the JSON itself. Text copied from a document or chat app can contain curly quotes instead of straight double quotes, which no JSON parser accepts. And a response copied from a terminal sometimes includes HTTP headers or a log prefix before the opening brace. Remove anything before the first brace or bracket and after the last one, then try again.

{"a":1,}          trailing comma
{a:1}             unquoted key
{'a':1}           single quotes
{"a":1} // note   comment after the document
{"n":NaN}         not a JSON value

Large numbers and duplicate keys are kept as written

A formatter built on JSON.parse followed by JSON.stringify quietly rewrites data. JavaScript numbers are IEEE 754 doubles, so an ID such as 9007199254740993 becomes 9007199254740992, and 19.990 becomes 19.99. If an object has the same key twice, only the last value survives. RFC 8259 notes that integers beyond 2^53 minus 1 are not reliably interoperable and that names should be unique, but real payloads break both rules.

The socket.help formatter validates with the parser and then re-indents the original text instead of re-serializing it. Number literals keep their exact digits and duplicate keys stay visible. That makes it suitable for inspecting a payload before your own code parses it, because you see what was actually sent rather than what a parser decided to keep.

If you find a large integer ID in a payload, that is a hint for your own code too. Many APIs send such IDs as strings for exactly this reason. If yours sends them as numbers, read them with a parser that supports big integers, or ask the provider whether a string form is available.

Input:
{"id":9007199254740993,"id":2,"price":19.990}

Output:
{
  "id": 9007199254740993,
  "id": 2,
  "price": 19.990
}

Format JSON from a script or the terminal

The same formatter is available over HTTP, through the CLI, SDK, SSH, and MCP, using the tool ID json and an optional action of format or minify. Hosted runs are different from the browser page: the input is sent to the server for processing. Results are not kept as execution history, but use the browser page for anything sensitive.

Hosted input is limited by your plan: 64 KiB without an account and 256 KiB with a free account. Only successful runs count toward the daily allowance, which is 100 runs without an account. In the browser, the formatter accepts up to 1 MiB of input.

curl https://socket.help/api/tools/json/run \
  -H 'Content-Type: application/json' \
  -d '{"input":"{ \"ready\": true, \"count\": 2 }","options":{"action":"minify"}}'

socket-help run json < response.json

Limits worth knowing

Nesting is limited to 128 levels, and formatted output is limited to 4 MiB. Deeply nested or very large documents are better handled by a streaming tool on your own machine. The output is a string, so the hosted response wraps it in a JSON field called output; your script needs to read that field rather than the raw response body.

If you need to convert the data rather than tidy it, use a converter instead. JSON to CSV flattens an array of objects into rows, and the data format converter moves between JSON and YAML. For YAML configuration, the YAML formatter checks for duplicate keys and unsupported tags.

Sources

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format ↗