Validating Data Formats Explained

Before any tool, API or pipeline can use your data, it has to be able to read it. Validation is the step that answers “is this data actually in the shape it claims to be?” — and getting it right saves you from cryptic failures deep inside a deploy or a production request. This guide explains what validation really means, the traps hiding in each common format, and how to read the error messages that point you at the fix.

Two very different questions: well-formed vs valid

People say “is my JSON valid?” to mean two different things. Keeping them apart is the single most useful idea in this whole topic.

• Well-formedness — does it parse? This is purely about syntax. Are all the braces and brackets matched, all the quotes closed, all the XML tags balanced? A well-formed document is one a parser can turn into a data structure without error. It says nothing about whether the content makes sense.
• Schema validity — does it match the rules? This is about structure and content. Given that the data parsed, does it also obey a schema — a separate description of which fields are required, what types they must be, and what values are allowed? Tools like JSON Schema (for JSON/YAML) and XSD (for XML) express these rules.

A quick example. This JSON is well-formed and schema-valid against “a person needs a name string and an age number”:

{ "name": "Ada", "age": 36 }

This is well-formed but not valid against that schema — it parses fine, but age is the wrong type and name is missing:

{ "age": "thirty-six" }

And this is not even well-formed — it never parses, so schema validity is irrelevant:

{ "name": "Ada", "age": 36, }

The order matters: you must be well-formed before schema validity is even a question. Most day-to-day “my config broke” problems are well-formedness failures — a stray comma, a bad indent, an unclosed tag.

Per-format gotchas

Every format has its own small print. These are the mistakes that trip people up most.

JSON

JSON is strict, and that strictness surprises people who write it by hand:

• Trailing commas are not allowed — [1, 2, 3,] is invalid.
• Single quotes are not allowed — keys and strings must use double quotes. {'a': 1} fails; {"a": 1} works.
• Comments (// or /* */) are not part of JSON at all.
• Keys must be quoted strings, and the top level is usually a single object or array.

JSON5 and JSONC relax some of these, but standard RFC 8259 JSON does not.

YAML

YAML is whitespace-significant, which makes it readable but fragile:

• Indentation must use spaces, never tabs — a single tab character causes a parse error, and it is invisible in most editors.
• Inconsistent indentation silently changes nesting, so a value can end up on the wrong key.
• The “Norway problem”: unquoted no, yes, on, off (and y/n) are interpreted as booleans under YAML 1.1. The country code NO becomes false; a version 1.0 may become a number. Quote anything you want kept as a literal string.
• A leading %, @, ` or : in an unquoted scalar can also break parsing.

XML

XML is verbose but has firm rules:

• Exactly one root element — two top-level elements is an error.
• Every tag must be closed — either <p>…</p> or self-closed <br/>; unclosed tags are the most common failure.
• Tags must nest properly — <b><i>x</b></i> is invalid.
• Special characters must be escaped in text and attributes: & → &, < → <, > → >. A bare & (e.g. in AT&T) is the classic XML error.
• Tag names are case-sensitive: <Item> and <item> are different.

CSV

CSV looks trivial until a value contains a delimiter:

• Any field with a comma, double quote or newline must be wrapped in double quotes; a literal quote inside is doubled ("").
• Ragged rows — rows with more or fewer columns than the header — usually mean a missing quote shifted everything after it.
• Mixed line endings and stray BOM bytes can confuse naive parsers.

The loose standard here is RFC 4180.

TOML, INI, .env and .properties

These key/value config formats are simpler but still have edges:

• TOML is strict and typed: strings need quotes, tables are [section], and it has real datetime and array types. Duplicate keys are an error.
• INI is loosely defined — key=value under [section] headers — with quoting and comment rules that vary by parser.
• .env files are KEY=value per line; values with spaces or special characters usually need quoting, and there is no formal standard.
• .properties (Java) use key=value too, but treat : as a separator, need backslash escapes, and expect ISO-8859-1/unicode-escaped characters.

Reading error messages

A good validator gives you a line and column for the first error. That location is the fastest route to a fix — the real problem is usually at or just before the reported spot. Some common patterns:

Message hint	Likely cause	Common fix
“Unexpected token }”	Trailing comma before it	Remove the comma
“Expected , or }”	Missing comma between items	Add the separator
“bad indentation” (YAML)	Tab used, or mismatched spaces	Replace tabs with spaces
“no element found” (XML)	Unclosed or missing root tag	Close the tag
“not well-formed (invalid token)”	Bare & or < in XML text	Escape it (&amp;)

If the reported line looks fine, check the line above it — a missing comma or unclosed quote is often only detected when the parser reaches the next token.

Common validation errors by format

Format	Most common validation error
JSON	Trailing comma / single quotes
YAML	Tabs in indentation, or the Norway boolean trap
XML	Unescaped &, or an unclosed tag
CSV	Ragged rows from an unquoted comma or quote
TOML/INI	Unquoted string values, or duplicate keys
.env/.properties	Unquoted values with spaces or special characters

When and where to validate

Validate early and often — the earlier a format error is caught, the cheaper it is to fix:

• Config files — validate *.json, *.yaml, *.toml before an app reads them, so a typo fails loudly instead of silently misconfiguring a service.
• CI pipelines — add a validation step so a malformed file fails the build, not production.
• Before deploy — a broken YAML manifest or JSON config should never reach a live environment.
• API payloads — validate incoming request bodies (well-formed and schema-valid) at the edge before they reach business logic.

How CodingSetu validation works

Our Validators check well-formedness entirely in your browser: they parse JSON, YAML, XML, CSV, TOML and more, and report the line and column of the first syntax error. They do not run full schema validation (JSON Schema, XSD) for every format — for schema checks, wire a dedicated validator into your build pipeline.

When a file doesn’t parse, the Repair tools can often fix it automatically — stripping trailing commas and comments from JSON, converting single quotes, closing XML tags, escaping stray characters and re-quoting CSV fields — so you get valid output without hunting for every error by hand.

Because everything runs client-side, your data is never uploaded, which makes it safe to validate secrets, private configs and internal payloads.

References

• RFC 8259 — the JSON data interchange format.
• YAML 1.2 specification — the YAML language spec.
• Extensible Markup Language (XML) 1.0 — the W3C XML specification.
• JSON Schema — a vocabulary for validating JSON structure and content.
• RFC 4180 — the common format for CSV files.

Try it

Paste your data into the Validators to catch syntax errors with a line and column, then use the Repair tools to fix broken JSON, YAML, XML or CSV — all in your browser, with nothing uploaded.