Valida

Validation as accept-or-reject parsing

Before an application trusts a document, it must answer a narrower question: is this text well-formed for the format it claims to be? Validation in this family means syntactic and structural checks—can a standards-aware parser consume the input without error—not full business-rule or schema certification (unless a format’s “valid” definition already includes schema).

The Valid tools share that mission across HTML, XML, SVG, JSON, YAML, and CSV. Begin with Valid JSON if you are debugging API payloads; the same idea applies to markup and tabular text under the siblings below.

What “valid” means by format

Formats disagree on how deep “valid” goes:

• JSON — ECMA-404 / RFC 8259 grammar: matching braces, quoted keys, no trailing commas, legal number forms. There is no standard “JSON Schema” step inside bare parse validation.
• YAML — YAML 1.1/1.2 load success: indentation structure, allowed tags, and scalar styles. YAML can express types and anchors that JSON cannot; a successful load is not the same as “safe to load untrusted YAML” in every language runtime.
• XML — well-formedness (matched tags, legal names, entity rules). Schema validity (XSD/DTD) is a separate, stricter layer.
• HTML — living HTML parsing rules differ from XHTML. Validators may flag unclosed elements, misplaced tags, or obsolete constructs depending on the engine’s conformance profile.
• SVG — XML-based graphics vocabulary. Well-formed XML is necessary; valid SVG also implies correct element nesting and attributes for the SVG namespace, though lightweight tools often focus on parse/well-formed checks first.
• CSV — rows of fields separated by a delimiter (often comma) with quoting rules (RFC 4180 family). “Valid” usually means consistent column counts, proper escape of quotes, and readable encoding—not that cell values match a business schema.

Knowing which layer you need prevents false confidence: well-formed XML can still violate an industry XSD; parseable JSON can still miss required fields.

Subtools in this family

• Valid HTML — check HTML markup for parser-level problems common in pages and fragments.
• Valid XML — check well-formed XML documents and snippets.
• Valid SVG — check SVG source as structured graphics markup.
• Valid JSON — accept or reject JSON text under standard grammar rules.
• Valid YAML — parse YAML and surface load/structure errors.
• Valid CSV — check delimited tabular text for structural consistency.

Pick the tool that matches the Content-Type or file extension you actually have. Do not validate YAML with a JSON parser or HTML with an XML-only checker unless you intentionally require the stricter dialect (for example XHTML).

Why browser-side validation helps

Local validation shortens the feedback loop when crafting fixtures, editing CMS fragments, or inspecting a copied response body. You see line-oriented errors before committing files or deploying configs. Keeping the document in the browser also avoids uploading sensitive drafts to a remote lint service—though the machine’s clipboard and screen sharing still expose content.

Validation here is complementary to unit tests: tests should still assert canonical fixtures in CI using the same libraries your production parsers use. Online checks are for exploration and triage; CI is for regression.

Error shapes worth recognizing

JSON. Unexpected token, unterminated string, trailing comma, single quotes, NaN. Editors that accept JSONC will pass locally and fail in strict production parsers.

YAML. Tabs vs spaces, incorrect indentation under a key, ambiguous unquoted strings (on/off booleanization in YAML 1.1), and duplicate keys depending on loader settings.

XML/SVG. Mismatched end tags, raw < in text, undefined prefixes, multiple top-level elements, or illegal control characters. SVG files that are HTML-embedded fragments may fail as standalone XML documents.

HTML. Overlapping tags, obsolete attributes, and void-element mistakes. HTML parsers often recover; a validator that reports issues may still describe a tree a browser will render—treat warnings as quality signals, not always as hard runtime failures.

CSV. Unescaped quotes, embedded newlines inside fields without quoting, mixed delimiters (comma vs semicolon), and ragged rows where column counts drift.

Validation versus transformation

Validators answer yes/no (and where it failed). Formatters and converters change bytes. A document can be invalid and still “look fine” in a browser’s forgiving HTML parser, or be valid JSON yet wrong for your API schema. Typical pipeline:

1. Validate syntax for the claimed format.
2. Optionally validate against a schema (JSON Schema, XSD, etc.) in application code.
3. Only then transform, merge, or persist.

Skipping step 1 wastes time on mysterious transform errors that were parse failures all along.

Security notes by format

• XML: billion laughs / entity expansion and external entity (XXE) attacks matter when parsers resolve DTDs or entities. Prefer parsers with external entities disabled for untrusted input.
• YAML: some loaders can construct arbitrary objects (!!python/object style tags). Prefer safe-load APIs for untrusted YAML.
• HTML/SVG: script and event-handler attributes are an XSS surface when markup is embedded into pages. Validation ≠ sanitization.
• CSV: formula injection in spreadsheet clients (=CMD(...)) is a concern when CSV is opened in Excel; structural validity does not neutralize that.
• JSON: generally safer to parse than the above, but huge payloads can still DoS memory; cap size on servers.

Practical workflows

• Paste an API error body into Valid JSON before blaming application logic.
• Check a Kubernetes or CI config fragment with Valid YAML when indentation looks suspicious.
• Confirm an export from a spreadsheet with Valid CSV before writing an importer.
• Verify hand-edited icons with Valid SVG before bundling.

Limitations

These tools do not replace domain schemas, accessibility audits, or full HTML conformance suites (for example every WHATWG check). They do not prove that XML satisfies a particular XSD, that JSON satisfies OpenAPI, or that CSV columns match a database DDL. They also do not sanitize active content. Use them as the first gate: structure first, meaning second.

Related tooling

After JSON validates, use Pretty-print JSON for layout or From JSON to XML for tree projection. Validation tells you whether the document is edible; other families decide what to cook.