Understand What Counts as Valid JSON
JavaScript Object Notation (JSON) is a text format for representing objects, arrays, strings, numbers, booleans, and null. An object uses curly braces and string keys; an array uses square brackets and ordered values. A complete JSON document can also be a single string, number, boolean, or null, although many APIs expect an object or array at the top level.
Unlike a JavaScript object literal, standard JSON requires double-quoted property names and string values. It does not allow comments, trailing commas, single-quoted strings, or the JavaScript values undefined and NaN. These rules are defined by RFC 8259 and implemented by normal JSON parsers.
{
"site": "Example Store",
"products": [
{"id": "0012", "price": 19.5, "available": true},
{"id": "0013", "price": null, "available": false}
]
}
This example is valid JSON. The product identifiers are strings so their leading zeros remain intact, whereas a price is a number or null when the value is unavailable. Indentation helps readers see the two products but is not what makes the data valid.
Separate Formatting from Validation and Schema Checks
For example, {"price":"free"} is syntactically valid JSON. A shopping application that requires price to be numeric might still reject it. A standard formatter is not automatically a JSON Schema validator, and a successful syntax check should never be presented as proof that a payload is correct for its destination.
Follow a Reliable JSON Checking Workflow
- Copy a representative sample. Remove passwords, tokens, personal records, and other secrets before entering content into any online tool.
- Paste the JSON into the available input. Check whether it contains one complete JSON value instead of surrounding explanations or code fences.
- Use the supported validation action. If the interface displays an error, locate the approximate line, column, or surrounding token shown.
- Correct the underlying syntax. Repair missing punctuation, invalid escapes, or unbalanced delimiters; do not simply delete data to make the warning disappear.
- Apply formatting if available. Inspect the nesting and review representative values after indentation changes.
- Test in the receiving application. Check field names, types, dates, IDs, and any schema requirements before deployment.
Exact buttons, file-upload options, downloads, and processing location depend on the deployed interface. Do not assume a feature is present solely because other JSON tools offer it.
Fix Missing Quotes, Trailing Commas, and Other Parsing Errors
Consider this deliberately invalid example:
{
'name': 'Desk lamp',
"price": 24,
"inStock": true,
}
The string delimiters use single quotes and the final object member ends with a trailing comma. A corrected version is:
{
"name": "Desk lamp",
"price": 24,
"inStock": true
}
Error messages often point near the character where a parser stopped, not necessarily the earliest character that caused the problem. A missing quote on one line can make a later comma appear invalid. Examine the preceding key-value pair and its delimiter before making changes.
Handle Escaped Characters and Unicode Properly
A JSON string must escape any literal quotation mark that belongs inside the value. A backslash also needs escaping, and control characters such as a newline must use escape sequences. For example:
{
"message": "She said \"Ready\"",
"folder": "C:\\reports",
"lines": "first\nsecond"
}
When the JSON is parsed, escaped quotes become ordinary quote characters inside the message, and \n represents a newline. A formatter can rearrange whitespace between tokens without changing that meaning, but editors must not replace escape sequences with invalid literal control characters inside strings. Non-ASCII text is allowed in JSON; it does not need to be converted to ASCII to be valid.
Review Duplicate Keys and Number Precision
Two identical keys can appear in source text, such as {"status":"draft","status":"live"}. RFC 8259 recommends unique object member names because implementations disagree on how duplicates should be handled. Some parsers keep only the last occurrence. A normal syntax check may accept such input, so review duplicate fields independently when consistency matters.
Numbers deserve similar care. The JSON number 12345678901234567890 may be beyond exact integer precision in certain programming environments even though its text is grammatically valid. Identifiers, phone numbers, and long account references should commonly be represented as strings. Also remember that JSON has no built-in date type: a value such as "2026-11-06" is simply a string until software interprets it.
Keep JSON-LD Structured Data Parseable
Website owners often use JSON-LD to describe entities such as organizations, articles, and products. JSON-LD uses JSON syntax, so a missing quote or comma can stop the structured data from being parsed. However, valid JSON syntax does not prove that a Schema.org property is appropriate or that a page meets search-engine eligibility requirements.
If you are preparing website markup, first check the JSON syntax. Then inspect the types and properties with the Structured Data Extractor and Syntax Checker or the relevant authoritative testing service. The Structured Data Generator can be useful for a separate markup-authoring workflow. Avoid adding duplicate JSON-LD through an article when your WordPress SEO plugin already outputs the same entity markup.
Formatting Does Not Automatically Repair Meaning
Pretty-printing generally changes indentation, spacing, and line breaks outside strings. Minifying does the reverse by removing unnecessary whitespace. Neither should be used as a substitute for checking data accuracy. If an editor silently converts strings to numbers, sorts keys, or rewrites values, compare the result with the source before using it.
For bulk exports or spreadsheets, use the CSV and JSON Converter when a format change is required. For problems with CSV quoting and row consistency, the CSV Structure Validator addresses a different issue. These tasks are related, but they are not interchangeable with JSON syntax validation.
Protect Sensitive Content During Online Checks
A JSON payload may contain API keys, private URLs, customer names, access credentials, or session tokens. Before pasting it into any website, verify whether parsing occurs locally in the browser, whether content is transmitted to a server, and whether logs or saved histories exist. Do not infer privacy protections from the appearance of the interface.
Even when a tool formats data correctly, treat untrusted strings as data when rendering them elsewhere. JSON parsing alone does not sanitize malicious HTML or make a value safe to place into an HTML page. Apply contextual escaping and the receiving platform’s security controls where appropriate.
Questions About JSON Validation and Formatting
Is JSON the same as a JavaScript object?
No. JSON is a strict text format with its own grammar. JavaScript object literals can use language features that are not valid JSON, including comments and certain unquoted property names.
Can valid JSON still cause an API error?
Yes. An API may expect specific required properties, accepted values, data types, or authorization details. Syntax validation only establishes that the text can be parsed.
Does changing indentation affect JSON values?
Whitespace outside strings is insignificant in JSON, so normal pretty-printing should not change the represented data. Whitespace inside a quoted string is part of its value and must be preserved.
Are JSON comments and trailing commas ever allowed?
Not in standard JSON. Related formats and some permissive parsers may accept them, but content intended for interoperable JSON processing should follow the standard rules.
Do I need JSON Schema validation?
Use it when your application has requirements such as mandatory fields, numeric ranges, or allowed data types. A syntax validator is a useful first check but cannot enforce those constraints by itself.
