Payload Validator

Reviewed 1d ago.

• tools: 5 tools scanned
• metadata: scanned

No findings.

Tools (5)

• validate_json

  Validates a JSON document and reports every problem with an exact line and column. Use this whenever you need to know why a JSON payload is failing, or to check a JSON document you or a user produced before sending it somewhere that will reject it. Do not do this by reading the JSON yourself. Three of the findings are invisible to inspection and to JSON.parse alike: (1) Duplicate keys. `{"port":8080,"port":9090}` is accepted by every mainstream parser, which keeps the last value and discards the first without a word. Reading it, you cannot see which one the consumer will use, because the answer differs by language. (2) Integer precision loss. `9007199254740993` parses as `9007199254740992` — quietly, because JSON numbers are IEEE-754 doubles in nearly every parser, exact only to 2^53-1. Any 64-bit ID (Twitter, Discord, most database bigints) is in the lossy range. This tool proves the loss with exact BigInt arithmetic rather than estimating it. (3) Lone surrogates. `"\ud83d"` alone i

• validate_yaml

  Validates a YAML document, including the values that mean different things to different YAML loaders. Use this for any YAML you are about to write or have just been given — CI configs, Kubernetes manifests, docker-compose files, OpenAPI specs, Ansible playbooks. Do not reason about YAML type resolution yourself. It is the single most reliable way to be confidently wrong about a config file, because YAML 1.1 and YAML 1.2 resolve the same plain scalar to different values and real loaders disagree about which to implement — PyYAML is 1.1, Go's yaml.v3 and the yaml npm package are 1.2: - `no`, `yes`, `on`, `off`, `y`, `n` are booleans in 1.1 and strings in 1.2. A country list containing `no` loses Norway. This is known as the Norway problem. - `on:` as a KEY, as in every GitHub Actions workflow, is the boolean `true` under 1.1, so the key is not "on" at all. - `0755` is 493 under 1.1 (octal) and 755 under 1.2 (decimal). Both are numbers, so nothing looks wrong; a file mode is simply the

• validate_xml

  Validates an XML document for well-formedness, namespace correctness, and the entity-based attacks that arrive as XML. Use this before parsing XML you received, and when an XML document is being rejected by something that will not say why. Do not eyeball this. Four classes of genuinely invalid XML are accepted by ordinary well-formedness checkers, so "it validated" does not mean what it appears to: (1) Two root elements. `<a/><b/>` is not a valid XML document; XML permits exactly one outermost element. Concatenated records hit this constantly. (2) Undeclared namespace prefixes. `<x:a>` with no `xmlns:x` is well-formed as raw XML and invalid under Namespaces in XML — so it passes a syntax check and is then rejected by XPath, XSLT, SOAP and every schema validator. (3) Undeclared entities. XML predefines only five (`&lt; &gt; &amp; &apos; &quot;`). `&nbsp;` is an HTML entity and is simply undefined in XML. (4) A bare `&`, almost always arriving inside a URL. Security findings, which ar

• validate_csv

  Validates CSV text against RFC 4180 and reports ragged rows individually, with both field counts. Use this before loading a CSV, and whenever a CSV-derived number looks wrong. Do not attempt this by reading the file, and be aware that loading it successfully proves nothing. The failure that matters is the ragged row: a file where one row has six fields and the header has five loads without complaint almost everywhere — pandas pads or throws depending on the engine, Excel shifts the columns, and `split(",")` silently mis-assigns every field after the extra one. Nobody notices until a figure is wrong in a report. This reports it as "row 4813 has 6 fields; the header has 5", per row. The other half is the delimiter. A European CSV is semicolon-separated because the comma is the decimal separator; reading it as comma-separated yields one column of nonsense and no error. The delimiter is sniffed from the header — ignoring quoted regions so their contents cannot vote — and always reported

• validate_auto

  Detects whether a payload is JSON, YAML, XML or CSV, then validates it. Use this when you have a blob of text and do not know what it is — a file with no extension, a clipboard paste, a response body with an unhelpful content type, or a config file whose format you would otherwise have to guess. Detection is structural and the reason is always returned, so the assumption is visible rather than hidden: a leading `<` is XML, a leading `{` or `[` is JSON, a `%YAML` directive or `key: value` lines are YAML, and a consistent delimiter count across multiple lines is CSV. JSON is checked before YAML on purpose, because JSON is a strict subset of YAML 1.2 and every JSON document would otherwise be ambiguous. If the detected format does not validate but JSON or XML does, the result is corrected and `detection.corrected` is true. Only those two can win a correction, because only they have decisive grammars — CSV will read almost any text as a valid single-column file, so "it validates as CSV"