Choose Format / validate and pick two or four spaces. The tool checks JSON syntax, then arranges the existing tokens. It does not replace a long integer with a rounded one or change exponent notation, string escapes, or member order.
Read syntax errors as syntax errors
Unquoted property names, trailing commas, comments, and unfinished strings are not accepted here. An error means the editor did not produce new JSON. This is not a schema validator: it does not verify required fields, check API-specific rules, or detect duplicate member names.
Choose Minify for a compact version
Minification removes formatting whitespace outside strings. Spaces inside a value such as "New York" remain. Download the result as .json. If the destination needs one row per object rather than JSON, try the CSV and JSON converter instead.
Format and check JSON without changing its values
Choose between formatting, minifying and validating
Start with the reason you opened the file. If you need to read an object or see which values belong to an array, select Format / validate. Two spaces keeps nested lines short; four can make indentation easier to spot when the document is shallow. The visual layout changes, but the JSON tokens stay in their original order. If you need a compact value for a configuration field that accepts JSON, select Minify / validate instead.
Both actions check the input syntax. There is no separate requirement to minify before formatting or vice versa. Choose the action that produces the form you actually need. An error means the input did not pass syntax validation; it does not mean every line is wrong. Start by checking the area around the reported position and the value immediately before it.
Keep the original before making edits. Format a copy when you want to see the structure, then use that readable version to correct the smallest part necessary. If you are comparing changes with a colleague, use the same indentation on both copies before looking for value differences.
Follow a nested sample from one line to several
Paste the following single line into Original. It contains one object, an array of two objects and a string with two spaces between its words. The number at the top is deliberately longer than a JavaScript safe integer.
With two-space formatting, the two items should each become easier to read as separate objects. The items property remains an array. The first sku is still the string "0017"; it does not become the number 17. The double space inside the label stays because it belongs to a string value. Whitespace outside that value is what changes.
Switch to Minify and compare the result with the original one-line sample. The label should still have two spaces, the digits of the batch value should be unchanged and the item order should still be the same. This makes a good quick check when you are learning what the editor does before trying a real configuration or export.
Understand what number preservation does and does not mean
Some formatters parse JSON into host-language values and then build a new document from those values. That can change the original spelling of a number, collapse repeated keys or round an integer when it exceeds the host's exact range. PasteCleanly uses a parser to check syntax but formats the existing tokens. This is why a value written as 1e-7, -0 or 9007199254740993 can be copied out with the same representation.
That preservation applies to the text leaving the formatter, not to every application that reads it. If a consuming service interprets an identifier as a floating-point number, the service may still round it. If you own both sides and the schema permits it, represent identifiers as strings to preserve their exact digits. Do not change the types of existing fields just because formatting preserved the number; the receiving contract decides what is correct.
The same distinction applies to escaped strings. A value written using a Unicode escape can display the same character as a literal value when parsed. This editor keeps the escape spelling rather than substituting the visible character. Use a decoded value viewer if the question is what a specific consumer actually sees.
Find the first syntax mistake without rewriting the payload
A JSON parser expects double quotes around object keys and string values. Single quotes, bare keys and inline comments can be valid in some programming contexts but are not valid JSON. If a snippet begins with a language declaration, an assignment or Markdown fences, copy only the JSON value. Then check whether the first opening bracket or brace has the corresponding closing character.
Try {"name":"Ava","active":true,} as a deliberately invalid sample. The final comma appears before the closing brace even though there is no next property. Remove that comma and validate again. This is different from a comma inside a string such as "Leeds, UK", which is part of the value and must stay.
When the error position seems late, read the line immediately before it. An unclosed string or missing comma can make the parser report the next recognizable character rather than the original mistake. If the source is long, reproduce the issue with the smallest complete object or array you can isolate. Repair it there, then apply the same change to the original with a clear record of what you changed.
Check the shape after syntax passes
Valid syntax does not tell you whether the destination wants an array, a single object or a particular nesting structure. An object with an items array and a bare array of items may contain identical records but satisfy different import rules. Use the destination's example or schema to check the root and the keys before sharing the formatted text.
Then check the types. The string "false" is not the Boolean false. The text "null", the value null, an empty string and a missing property can each carry a different meaning. Compare one ordinary record with one containing a blank value and one containing a long identifier. A generic formatter cannot infer how your particular importer distinguishes those cases.
Repeated member names also require attention. Formatting does not remove or flag them, and the receiving application may choose one value or reject the document. If you see the same key twice within an object, determine which field the source actually intended. Use a schema validator or the actual application's preview when you need a stronger check than syntax.
Compare two payloads without mistaking indentation for an edit
Keep both source payloads. Format each with the same indentation and paste the two formatted versions into the text diff checker. Start with line mode to find the changed fields. Switch to character mode on a short value if the change is a single digit, an escape or a space inside a string. This workflow removes formatting noise from many comparisons without discarding the original evidence.
Check changes in arrays especially carefully. Moving a record can produce several removed and added lines even if no value changed. In many applications array order is meaningful. An object with keys in a different order can also show as a textual change; the formatter does not sort keys and the diff is not a semantic JSON comparator. Decide what order means in your destination before treating a reordered field as a data change.
For a review, report the specific fields and the expected behavior rather than forwarding a long diff alone. Check the value before and after, its type and which parent object it belongs to. When a large payload contains repeated property names across different records, identifying the enclosing record helps prevent reviewing the wrong occurrence.
Choose a table converter when the data needs rows
If your source is comma-separated text, formatting it as JSON will not create object keys automatically. Use the CSV and JSON converter first, decide whether the first row is a header and inspect whether fields that look numeric should stay as strings. Then return to this formatter if you need a consistent presentation or a compact copy for a system that expects JSON.
If the recipient only wants to read a few records in a project ticket, a Markdown table may be clearer than a long JSON document. Build it from a separate representative CSV sample and keep the machine-readable export unchanged. For nested objects or arrays, do not assume a flat table can represent all the structure. Agree on the fields and shape first.
The guide to JSON, Markdown and HTML text illustrates how to keep the original data and make separate versions for software and documentation. That distinction matters when an HTML example requires escaped characters but the JSON payload must still preserve the original values exactly.
Verify the version you will actually use
After copying or downloading the result, reopen it in the tool or application that will consume it. Check that the first and last record are present, that an example with escapes is readable and that a long identifier has not been altered by the destination. If the target expects a configuration document, use its validation or test-import workflow before replacing a working copy.
For a report you share with another person, say whether the change was formatting only or whether you also corrected syntax or edited values. If you removed a trailing comma, note that separately from reindentation. Keep a copy of the unedited source so someone can trace an unexpected result without guessing which step changed it.
Do not paste production secrets into an issue or public documentation. The formatter operates in the browser, but copying the result elsewhere is a separate decision. When reproducing a problem for someone else, replace sensitive values with safe stand-ins that keep the same type and structure. A short example with the original syntax issue is usually more useful than an entire configuration file.
PasteCleanly