How to Format and Validate JSON Online

If you work with APIs, configuration files, or any kind of structured data, you deal with JSON regularly. And if you have ever stared at a wall of minified JSON trying to find a missing bracket, you know why formatting matters. A browser-based formatter handles the entire job locally without uploading your data to a server.

What JSON formatting does

Raw JSON from an API response or a minified file looks like this:

{"users":[{"name":"Alice","age":30,"roles":["admin","editor"]},{"name":"Bob","age":25,"roles":["viewer"]}]}

A formatter transforms it into something readable:

{
  "users": [
    {
      "name": "Alice",
      "age": 30,
      "roles": ["admin", "editor"]
    },
    {
      "name": "Bob",
      "age": 25,
      "roles": ["viewer"]
    }
  ]
}

Same data, but now you can actually read it, spot errors, and understand the structure.

How to format JSON online

1. Paste your JSON into the input field. The formatter will immediately detect syntax errors and validate the structure.
2. Choose your indentation: select 2 or 4 spaces, or click Minify to compress the JSON into a single line.
3. Copy the result: the formatted output includes color-coded syntax highlighting. Copy it to use in your code, config file, or documentation.

A brief history of JSON

JSON (JavaScript Object Notation) was specified by Douglas Crockford in 2001, formally documented in RFC 4627 (2006), and standardized as ECMA-404 in 2013 and ISO/IEC 21778 in 2017. Crockford did not invent JSON: he extracted it from a subset of JavaScript object literal syntax that was already in use, and gave it a name plus a single-page specification at json.org.

JSON quickly displaced XML for web APIs because it is dramatically simpler. An XML response is verbose with opening/closing tags; the equivalent JSON is half the size. Browsers can parse JSON natively (JSON.parse, JSON.stringify since ECMAScript 5 in 2009) with no XML parser required.

By 2015, every major API in the world spoke JSON: REST APIs, GraphQL queries, WebSocket messages, configuration files (package.json, tsconfig.json, .vscode/settings.json), and even databases (PostgreSQL JSONB, MongoDB BSON which is JSON-like). It became the lingua franca of structured data on the web.

The simplicity of JSON is also its limitation: no comments, no trailing commas, no date type, no binary support. Several JSON variants emerged to address these gaps (see "Alternative JSON-like formats" below).

Common JSON errors and how to spot them

Most JSON errors come down to a few common mistakes:

• Missing or extra commas: a comma after the last item in an array or object is invalid in JSON (unlike JavaScript)
• Unquoted keys: JSON requires double quotes around all keys: "name" not name
• Single quotes: JSON only accepts double quotes: "value" not 'value'
• Trailing commas: {"a": 1,} is invalid; remove the comma after the last entry
• Comments: JSON does not support // line or /* block */ comments; most parsers reject them
• Undefined / NaN / Infinity: JSON only allows numbers, strings, booleans, null, arrays, and objects. JavaScript values like undefined, NaN, or Infinity are not valid
• Function values: a function reference cannot appear in JSON
• Hex or octal numbers: only decimal numbers are valid (0xFF and 0o17 are not)
• Leading zeros: 01 is invalid in JSON; use 1
• Hexadecimal escapes: only \u Unicode escapes are allowed in strings, not \x or \0
• Duplicate keys: technically valid per spec, but most parsers silently use the last value; rely on this at your own risk
• UTF-8 BOM: a byte-order mark at the start of a file is not valid JSON and breaks strict parsers
• Trailing whitespace or content: any text after the closing ] or } makes the document invalid

A good formatter highlights exactly where the error is, so you can fix it immediately instead of guessing.

JSON data types

JSON has exactly 6 data types:

Notably missing: dates (use ISO 8601 strings), binary data (use Base64 strings), comments (use a separate documentation field), and bigint (JSON numbers are double-precision; values >= 2^53 lose precision).

When to format vs minify

Format (pretty-print) when you need to:

• Read and understand the data
• Debug API responses
• Edit configuration files
• Share JSON with colleagues
• Commit to version control (cleaner diffs)

Minify when you need to:

• Send data over a network (smaller payload = faster transfer)
• Store JSON in a database or log where readability does not matter
• Embed JSON in a URL parameter or form field
• Generate compact API responses

The size difference is significant: a typical 50 KB pretty-printed JSON minifies to about 30 KB. For high-traffic APIs, minified responses save bandwidth. For human-edited files, formatted is essential.

Alternative JSON-like formats

When JSON's strictness is a problem, several variants relax the rules:

For data interchange (API responses, configuration), stick with strict JSON. For human-edited config, JSON5 or JSONC are friendlier. For data streaming, NDJSON is the de facto standard.

Common pitfalls

• Numbers losing precision: JSON numbers are IEEE 754 doubles. Integers larger than 2^53 (9,007,199,254,740,992) lose precision. Transmit large IDs as strings ("id": "12345678901234567890").
• Unicode escapes mangled by editors: some editors auto-convert é to é on save, or vice versa, which can cause parsers to behave unexpectedly. Use UTF-8 throughout.
• Pretty-printing dates wrong: dates as ISO 8601 strings ("2026-05-20T13:00:00Z") are standard. Avoid Unix timestamps as strings; they look like numbers but are usually intended as dates.
• Whitespace in keys: {"first name": "..."} is valid JSON but breaks many ORMs and code generators that expect identifier-safe keys.
• Empty values vs missing keys: {"a": null} and {} (no a at all) are different things. Pick one convention and document it.
• Bigint mismatch: PostgreSQL bigint columns serialized as JSON numbers may lose precision. Use strings for IDs over 2^53.
• Trailing newline: some tools add a trailing newline after the closing brace; some strict parsers reject it. JSON-stringify produces no trailing newline.
• Encoding mismatch: JSON spec requires UTF-8 (or UTF-16/UTF-32 with BOM). Latin-1 with non-ASCII characters fails. Always serialize as UTF-8.
• Stringified JSON in JSON: {"data": "{\"nested\": 1}"} is a double-escape mess. Either nest the object directly or pick a base64-encoded JSON convention.
• Comments in the source file: if you check in JSONC or JSON5 to a system that expects strict JSON, parsing fails. Convert to strict JSON in your build step.

Tips for working with JSON

• Validate before sending: if you are building an API request manually, paste your JSON into a validator first. A single misplaced comma can cause confusing errors on the server side.
• Use 2-space indentation for deeply nested data. It keeps lines shorter and the structure easier to scan.
• Bookmark the tool: if you work with JSON regularly, having a formatter one click away saves time compared to searching for one each time.
• Use jq for command-line work: jq (and the jq-language alternatives like gron, dasel, yq) are essential for filtering and transforming JSON on the command line.
• Use a JSON schema for validation: for important formats (API contracts, config files), define a JSON Schema and validate against it. Tools like ajv (JavaScript), python-jsonschema, or VS Code's built-in schema validation prevent shape errors.
• Use Postman or Insomnia for API requests: these tools have built-in JSON formatters and validators, syntax highlighting, and request history.
• Run JSON through prettier in your codebase: Prettier formats JSON consistently; integrate it as a pre-commit hook so formatting is never a code review concern.
• For diffing, sort keys first: JSON object keys are unordered. A diff of {"a":1,"b":2} vs {"b":2,"a":1} shows everything changed unless you sort keys first. Use jq -S or similar.

Privacy and confidential JSON

The JSON formatter runs entirely in your browser. The JSON you paste, intermediate processing, and the formatted output all stay on your device. Nothing is uploaded to a server, logged, or shared with anyone.

This matters because JSON often contains extremely sensitive data: API responses with customer records and email addresses, authentication tokens and session data, internal API schemas that reveal product architecture, configuration files with database passwords, financial data from accounting APIs, medical records from FHIR APIs, internal company structure from HR APIs, debug payloads with stack traces revealing infrastructure. Cloud JSON formatters log every paste in their request logs, sometimes retain them for "service improvement," and have been involved in real incidents where pasted API responses leaked customer data and API keys. A browser-based formatter has zero exposure: the JSON never leaves your machine.

Browser-based formatting also works offline once the page is loaded, useful for formatting JSON on airplanes, in secure environments without internet access, or anywhere you cannot or should not paste API data (especially with embedded credentials) into a third-party service.