The file looks completely tidy and readable, but the system rejects it with a vague error like "Unexpected token." The problem usually isn't visual — it's a small structural detail that violates the official JSON standard.
Formatting only arranges the visual shape of the text (spaces, new lines), while validation checks that the structure itself fully complies with the official JSON standard rules. Text can look beautifully formatted to the eye while being structurally invalid at the same time, and will get rejected by any strict system.
A trailing comma after the last item in a list or object is one of the most common errors, and hard to spot with the naked eye especially in long files. Also, using single quotes (') instead of double quotes (") around text, or writing a number in an unsupported format (like numbers with leading zeros), causes the entire file to be rejected.
The official JSON standard requires: mandatory double quotes around every key and string (not single quotes), boolean values must be entirely lowercase true or false (not True or FALSE), and there's no support for comments at all (neither // nor /* */), even though comments are accepted in many programming languages whose syntax draws from JSON.
Using the JSON Validator on Fawran Tools:
Formatting only arranges the visual shape, while validation checks the structure complies with the official standard.
Some tools are more lenient with minor errors, while strict production systems reject any deviation from the standard.
Yes, the standard requires true, false, and null entirely lowercase — any other form is a syntax error.
No, the official standard doesn't support comments at all, unlike similar formats like JSON5 or JSONC.
A tidy appearance isn't a guarantee of data validity — structural validation is the real test, and a quick validator tool saves you hours of manually searching for why a system rejected a file that looks perfectly fine to the eye.