Free JSON Formatter & Validator

Instantly format, pretty-print, and validate JSON. Detects syntax errors with position info, and shows key count, max depth, and byte size.

Enter your details
Result
Enter your details on the left, then press Calculate.

What is this calculator for?

You just pasted a 1,400-character API response into your editor and it's one giant line with no whitespace. Or you're debugging an API that returns malformed JSON and the error message is unhelpful. The JSON formatter pretty-prints minified JSON (adding indentation and newlines for readability), validates JSON syntax (identifying exactly where errors are), and minifies pretty-printed JSON when needed for transport efficiency.

JSON (JavaScript Object Notation) is the dominant data interchange format on the modern web. Used by virtually every REST API, configuration file, NoSQL document store, and inter-service communication. JSON syntax: objects (key-value pairs in {}), arrays (in []), strings (double-quoted), numbers, booleans, null. Strict syntax — single quotes don't work; trailing commas are illegal; keys must be strings; comments not allowed.

This formatter accepts JSON input, validates syntax, and outputs formatted or minified versions. Use during API debugging, config file editing, or any time JSON is hard to read in its raw form.

How to use this calculator

Paste your JSON into the input area. The formatter detects whether it's valid JSON and either pretty-prints it (adding indentation and newlines) or shows the syntax error with location.

For minification (removing whitespace for transport): the tool can convert pretty-printed JSON back to compact form. Useful when sending JSON over networks where size matters (API responses, embedded in URLs).

For validation: paste suspicious JSON, the tool reports syntax errors with line and column. Common errors: trailing commas (legal in JavaScript objects but not JSON), single quotes instead of double, unquoted keys, mismatched brackets.

Understanding your results

The formatter outputs either formatted JSON or specific error messages identifying where parsing failed.

JSON syntax essentials. Object: {"key": "value", "key2": 42}. Array: [1, "two", true, null]. Strings: must use double quotes. Numbers: no quotes (123, -45.67, 1.2e3). Booleans: true and false lowercase (Python's True/False capitalization is invalid JSON). Null: null lowercase. Nested: {"user": {"id": 1, "name": "Alice", "tags": ["admin", "owner"]}}.

Common JSON errors. Trailing comma after last item: [1, 2, 3,] — illegal in strict JSON, legal in JavaScript. Single quotes: {'key': 'value'} — illegal. Unquoted keys: {key: "value"} — illegal. Comments: {"x": 1 /* comment */} — illegal. These all work in JavaScript object literals but fail JSON parsing. JSON5 and JSONC are alternative formats that allow these; standard JSON does not.

Pretty-printing indentation. Standard practice: 2-space or 4-space indentation. Default is 2-space in most contexts (Node.js, Python json.dumps default). 4-space is more readable for deeply-nested structures but produces larger files. The choice is aesthetic; consistency within a project matters more than the specific number.

JSON vs alternatives. YAML: more human-readable, allows comments, but indentation-sensitive (whitespace errors common). TOML: configuration-focused, very clean syntax. XML: older, more verbose, still used in legacy systems. JSON's advantages: universal language support (parser in every modern language), simple syntax, compact, well-defined spec (RFC 8259). For data interchange between systems: JSON dominates. For config files: increasingly YAML or TOML. For data within a single system: language-native formats (Python pickle, etc.) sometimes used.

A worked example

Marcus is debugging a webhook integration. The third-party service is supposed to send him JSON but the request fails on his server.

He copies the raw webhook payload from his server logs: {name: "John Doe", email: 'john@example.com', age: 35, items: [1, 2, 3,]}

Pastes into the JSON formatter. Result: Error at line 1, column 2 — Unexpected token 'n' (expected string). The formatter highlights: unquoted key "name." Marcus identifies the first issue.

He fixes manually: {"name": "John Doe", "email": 'john@example.com', age: 35, items: [1, 2, 3,]}. Re-parses. Error: line 1, column 25 — Unexpected token "'" (string must use double quotes). He fixes the email quotes. Re-parses. Error: column 50 — unquoted "age". Fixes. Re-parses. Error at end: trailing comma in array. Fixes. Now parses successfully.

The webhook source is sending JavaScript object literal syntax, not JSON. He contacts the third-party service — they confirm their docs say "JSON" but the actual output is JS-formatted. Fix on their side. In the meantime, Marcus's server-side code is updated to use a lenient parser (jsonc or json5) that accepts the loose format.

Variation: API response that's "valid JSON but ugly." 4-line minified response that's actually a 200-line nested object. Pretty-printed: 200 lines of indented structure that's easy to scan. Marcus can quickly see which fields are present, which are null, which are nested how deeply. The pretty-print transforms the response from "wall of text" to readable structure in 1 click.

Related resources

For testing API endpoints that return JSON, use tools like Postman or curl. For regex pattern testing (often paired with JSON parsing), see Regex Tester. For other developer text tools, the Base64 Tool and URL Encoder. The JSON.org is the official reference for the format; RFC 8259 is the authoritative IETF specification.

Related calculators

base64url encoder

Frequently asked questions

What is JSON?

JSON (JavaScript Object Notation) is a lightweight text format for storing and transmitting structured data. It supports 6 data types: strings (double-quoted), numbers, booleans (true/false), null, arrays (ordered lists in []), and objects (key-value pairs in {}). It is the de facto standard for REST API responses and configuration files.

What are common JSON syntax errors?

The most frequent mistakes: (1) Trailing commas after the last item in an object or array — valid in JavaScript but banned in JSON. (2) Single quotes around strings — JSON requires double quotes. (3) Unquoted property keys — {"name": "John"} is correct. (4) Missing comma between properties. (5) Comments — JSON has no comment syntax. (6) NaN and Infinity — not valid JSON values.

What is the difference between JSON and XML?

Both are human-readable data interchange formats. JSON is more concise, natively maps to JavaScript/Python data structures, and is used in virtually all modern APIs. XML is more verbose but supports schemas (XSD), namespaces, mixed content, attributes, and XSLT — still common in enterprise systems, SOAP APIs, and document formats like Word (.docx) and SVG.

What's the difference between JSON and a JavaScript object?

JSON is a text format for serializing JavaScript-style objects (and other data) for transport between systems. JavaScript objects are in-memory data structures in a running JS program. Conversions: JSON.stringify(obj) converts a JavaScript object to JSON text. JSON.parse(text) converts JSON text to a JavaScript object. Syntactic differences from regular JS objects: JSON requires double quotes around keys and string values, no trailing commas, no comments, no functions or methods, no undefined values. JSON is a subset of JavaScript object literal syntax — stricter rules.

Why are comments not allowed in JSON?

Original design decision by Douglas Crockford (JSON's inventor) for simplicity and parsability. He explicitly removed comments to prevent people from putting parsing directives in them and forcing implementations to interpret. The trade-off: comments help humans read config files but are missing in JSON. Workarounds: use JSON5 or JSONC (variants that allow comments). Use YAML for human-edited config files (allows comments, more readable). For pure data interchange (machine to machine), JSON without comments is fine.

How do I handle large JSON files?

Several strategies. Streaming parsers: don't load entire file into memory; parse incrementally (Python's ijson, JavaScript's clarinet, Node.js streams). Database loading: import JSON directly into MongoDB or PostgreSQL JSONB columns for queryable storage. Conversion: convert to more efficient formats (Parquet, Avro) for analytical workloads. Visualization: jq command-line tool for filtering and querying. Browsers struggle with JSON files over 50-100 MB; command-line tools handle gigabytes easily. For 10+ GB JSON: convert to a proper database; JSON's text format is inefficient at scale.

What's JSONP and is it still used?

JSONP (JSON with Padding) is a workaround from the pre-CORS era. Older browsers blocked AJAX requests to different domains. JSONP got around this by including JSON wrapped in a function call, requested via a <script> tag (which had no cross-origin restriction). Used heavily 2008-2014. Largely obsolete now: CORS (Cross-Origin Resource Sharing) is the modern solution for cross-domain API requests. JSONP has security risks (executes arbitrary JS) that CORS doesn't. New code: use CORS. Legacy code: JSONP may still be encountered but should be replaced when possible.

What's the difference between JSON and YAML?

JSON: strict, machine-friendly, no comments, requires brackets and quotes. YAML: human-readable, allows comments, indentation-based (no brackets), supports more data types (dates, etc.). YAML is a superset of JSON in some sense — most JSON is also valid YAML. YAML advantages: easier for humans to write and read; great for config files (Kubernetes, Docker Compose, Ansible). JSON advantages: ubiquitous parser support; no whitespace sensitivity (avoids indentation errors); simpler spec. For APIs: JSON dominates. For configuration: YAML increasingly preferred. For programming language data: JSON. For human-edited config: YAML. Modern tooling often accepts both interchangeably.