JSON Formatter
Paste raw JSON, fix syntax problems, then switch between readable and compact output without leaving the page. This JSON formatter is built for the day-to-day work that happens around APIs, config files, logging payloads, webhooks, and exported data. If you have a one-line blob from a terminal, a response body copied from DevTools, or a settings object that became unreadable after too many edits, this tool turns it back into structured text you can inspect. It also tells you when the input is not valid JSON, which is usually the real problem. A missing quote, trailing comma, unescaped line break, or stray comment can break an integration fast. Formatting helps you see the shape. Validation helps you trust what you are about to copy into code, a request body, or a deployment config.
Quick answer
Formatting and validation run fully client-side, so your pasted JSON stays in the browser on your own device.
What this tells you
- •Formatting and validation run fully client-side, so your pasted JSON stays in the browser on your own device.
- •Pretty formatting adds indentation and line breaks so nested objects and arrays are easier to scan and debug.
- •Minified output removes unnecessary whitespace, which is useful when you need compact JSON for transport, storage, or embedding.
- •Validation checks JSON syntax, not business rules. A payload can be valid JSON and still be wrong for the API or schema you plan to send it to.
How to Use
- 1Paste JSON into the input area exactly as you received it. That could be an API response, a config object, a webhook sample, or a log payload.
- 2Click Validate & Format first when the structure is hard to read. If the JSON is valid, the output becomes indented and easier to inspect line by line.
- 3Scan the formatted result for the parts you actually care about, such as missing keys, unexpected null values, duplicated fields, or the nesting level of arrays and objects.
- 4If the tool reports an error, go back to the input and look for the usual syntax issues. Common causes are trailing commas, double quotes replaced with single quotes, comments copied from JavaScript, or pasted text that is not wrapped as a string value.
- 5Use Minify when you need the same data in the smallest readable machine format, for example before pasting JSON into an environment variable, request body field, or test fixture.
- 6Copy the output only after you confirm both the syntax and the structure. Formatting can tell you whether JSON parses, but it cannot confirm that an endpoint expects those keys or values.
Worked Examples
Pretty format a one-line API response
The original payload is valid, just cramped. After formatting, you can immediately see the user object, the roles array, and the boolean status without counting braces in a single line.
Catch a trailing comma before sending a request
JSON does not allow a trailing comma after the last property in an object or the last item in an array. This mistake is common when data is copied from JavaScript object literals.
Minify JSON for an environment variable
The data stays the same, but whitespace is removed. That is helpful when a deployment form or secret manager expects compact JSON in a single field.
Fix a package.json that npm refuses to read
Mateo pastes a scripts block from a JavaScript config into package.json, and npm refuses to start. This page returns the browser's parser message, which in Chrome reads Expected double-quoted property name in JSON at position 111 (line 1 column 112). Position 111 is the closing brace right after the stray comma. Firefox and Safari word the message differently but point at the same spot. Removing the comma and clicking Validate & Format prints the object with 2-space indentation across 12 lines and reports 5 top-level keys: name, version, private, scripts, and dependencies. Minify then collapses it back to 149 characters for an environment variable or a one-line fixture.
What RFC 8259 JSON allows and forbids
The rules that separate JSON from JavaScript object syntax, with the RFC 8259 section that states each one. Paste a rejected example into the formatter to see the parser message it produces.
| Rule | Valid example | Rejected example |
|---|---|---|
| Strings use double quotes (section 7) | {"city": "Austin"} | {'city': 'Austin'} |
| No trailing comma after the last member or element (sections 4 and 5) | [1, 2, 3] | [1, 2, 3,] |
| No comments, the grammar has no comment token (section 2) | {"port": 8080} | {"port": 8080 // default} |
| Literal names are lowercase true, false, and null (section 3) | {"active": true, "note": null} | {"active": True, "note": NULL} |
| Numbers cannot start with a leading zero (section 6) | {"code": 7} | {"code": 007} |
| Numbers cannot carry a leading plus sign (section 6) | {"delta": -5} | {"delta": +5} |
| NaN and Infinity are not JSON numbers (section 6) | {"ratio": 1.5e300} | {"ratio": NaN} |
| Exactly one top-level value, and it may be any type (section 2) | "hello" or 42 or [1, 2] | {"a": 1} {"b": 2} |
| Control characters inside strings must be escaped (section 7) | {"msg": "line 1\nline 2"} | A string with a raw tab or line break typed between the quotes |
| Names within an object SHOULD be unique (section 4) | {"id": 1, "name": "Ava"} | {"id": 1, "id": 2} parses, but this page keeps only id 2 |
| Interchange text is UTF-8 with no byte order mark (section 8.1) | A plain UTF-8 file | A UTF-16 file, or a UTF-8 file that starts with a BOM |
Source: RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format (IETF, December 2017), with section numbers in the first column. ECMA-404, 2nd edition (December 2017), defines the same grammar. RFC 8259 dropped the older RFC 4627 rule that a document had to be an object or an array. The syntax rows were checked against the JSON.parse behavior this page uses.
What this JSON formatter helps with and what it does not
A formatter solves a readability problem first. When a payload is compressed into one line, it becomes hard to answer practical questions. Which keys are siblings. Which values sit inside the same object. Whether an array holds strings, numbers, or nested objects. Pretty printing inserts line breaks and consistent indentation so the structure becomes visible. That matters when you are tracing a bug, comparing two responses, or checking whether a field moved after an API change.
Validation solves a different problem. It answers whether the text follows JSON syntax rules closely enough to parse. That means quoted keys, double-quoted strings, matching braces and brackets, commas only between items, and exactly one top-level value. If parsing fails, the tool can help you narrow the problem down to syntax, which saves time before you dig into deeper application logic.
What it does not do is schema validation or semantic review. A field named `userId` can still be the wrong type. A date string can still use the wrong format. A webhook body can still be missing required keys even if the JSON is perfectly valid. Use this page to clean and inspect the payload first, then validate it against the API contract or JSON Schema your project relies on.
Two of its limits come from the JSON standard itself. RFC 8259 section 4 says the names within an object SHOULD be unique and that software receiving duplicate names behaves unpredictably. The JSON.parse call this page uses keeps the last value, so {"id": 1, "id": 2} quietly formats as a single id of 2 with no warning. The same section notes that parsers differ on whether member order is visible to the calling program, so treat the key order in the output as whatever the parser returned, not as a guarantee. RFC 8259 section 6 adds that implementations built on IEEE 754 double precision cannot represent integers beyond 9,007,199,254,740,991 exactly, and this formatter inherits that limit: an id of 9007199254740993 comes back as 9007199254740992. Keep large numeric ids as strings before you format.
Three more limits come from what the page is. It validates syntax, not meaning, so checking a payload against a JSON Schema or an OpenAPI document is a separate step this tool does not perform. It runs the browser's own JSON.parse and JSON.stringify, defined in ECMA-262, so a very large document is held in that tab's memory and a multi-hundred-megabyte export can stall or fail even though no server is involved. And it rejects JSON5 and JSONC on purpose. Comments, trailing commas, single quotes, and unquoted keys belong to those formats, not to RFC 8259 JSON, so a tsconfig.json or a VS Code settings file that uses them fails here even though the editor accepts it.
Common mistakes
- Pasting a JavaScript object literal and expecting it to count as JSON. JavaScript allows comments, single quotes in many codebases, and sometimes unquoted keys. JSON does not.
- Assuming valid syntax means correct data. A payload can parse cleanly and still fail because a required field is missing, a number is stored as a string, or the endpoint expects a different nesting shape.
- Editing minified JSON directly when you are troubleshooting. Format first, make the change in the readable version, then minify only if you still need compact output afterward.
- Forgetting that duplicate keys are a logic smell. Many parsers accept them and keep only the last value, which can hide mistakes in hand-edited payloads.
Embed this calculator on your site
Paste this code where you want the calculator to appear. It is responsive, mobile-friendly, resizes automatically, and is free to use as long as the credit line stays in place.
<script src="https://calctide.com/embed.js" data-tool="json-formatter" async></script>
<p style="font-size:12px;margin:4px 0 0">JSON Formatter by <a href="https://calctide.com/tech/json-formatter/">CalcTide</a></p>Preview the embed at /embed/json-formatter/.