{"id":13147,"date":"2026-09-24T07:35:00","date_gmt":"2026-09-24T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13147"},"modified":"2026-11-04T22:47:46","modified_gmt":"2026-11-04T21:47:46","slug":"tutorial-checking-a-json-payload-before-it-goes-into-a-tag","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/tutorials-en-web-development\/tutorial-checking-a-json-payload-before-it-goes-into-a-tag\/","title":{"rendered":"Tutorial: Checking a JSON Payload Before It Goes Into a Tag"},"content":{"rendered":"

A JSON payload can be syntactically valid and still carry the wrong value. Three separate checks help: parsing the original text, checking interoperability risks, and validating the receiving application’s rules. Formatting alone covers none of these completely.<\/p>\n

The examples below run locally. The checker accepts exactly one JSON value, rejects duplicate object members and keeps decimal values without an intermediate binary floating-point conversion. It does not contact a tag manager or analytics service.<\/p>\n

\"Four
Four stages of JSON checking<\/figcaption><\/figure>\n

The actual JSON text as the starting point<\/h2>\n

JSON is a data format, not executable JavaScript. Object names and strings need double quotes. Comments, trailing commas, undefined, NaN and Infinity are outside the JSON grammar. The value categories are object, array, string, number, boolean and null; a document can also consist only of a scalar such as false or 42. Date and identifier conventions belong to the application schema.<\/p>\n

An apostrophe inside a double-quoted string is valid. An unescaped line break inside a string is not; the escaped sequence \\n<\/code> represents a newline. Different parsers issue different diagnostics, so a fixed count of \u201cloud\u201d and \u201csilent\u201d errors is not useful.<\/p>\n

The original response or file should be retained before formatting. A formatter may refuse malformed JSON and can discard duplicate members or change numeric representation. An error at position zero can come from a byte-order mark, HTML instead of JSON, an empty input or another unexpected first character. It does not diagnose a BOM by itself.<\/p>\n

Duplicate-name checks before information is lost<\/h2>\n

RFC 8259 recommends unique names within each object. Receivers handle duplicates differently: common parsers keep the last value, but rejection or preservation of all pairs is also possible. After conversion to an ordinary dictionary, the discarded value may already be unavailable.<\/p>\n

For example, {\"a\":{\"x\":1},\"a\":{\"y\":2}}<\/code> repeats the name a even though the paths to the final values, a.x and a.y, differ. A list of repeated streaming leaf paths cannot reliably detect this problem. Conversely, the same name in two separate objects is not a duplicate within one object. The checker uses Python’s object_pairs_hook<\/code> before building each dictionary, including nested objects and escaped names.<\/p>\n

Identifiers and the receiving schema<\/h2>\n

JavaScript Number uses binary floating point. Every integer in the inclusive interval from \u2212(2^53\u22121) to 2^53\u22121 is safe; outside that interval some integers are representable, but not every neighboring integer is distinct. The following Node.js example demonstrates a changed final digit.<\/p>\n

const parsed = JSON.parse('{"id":9007199254740993}');\nconsole.log(parsed.id); \/\/ 9007199254740992\nconsole.log(Number.isSafeInteger(parsed.id)); \/\/ false\nconst exact = JSON.parse('{"id":"9007199254740993"}');\nconsole.log(exact.id); \/\/ "9007199254740993" as a string\n<\/code><\/pre>\n
A string preserves this identifier when the receiving API permits a string. An API that requires a number needs its documented representation and limits; changing every identifier to a string unconditionally can make a valid request invalid. A digit-counting regular expression is not a complete precision check: it misses negative or exponent forms and can confuse numeric strings with numbers.<\/p>\n
A local checker with explicit extra rules<\/h2>\n
The file uses only Python’s standard library. Saving it as check_json.py<\/code> allows python3 check_json.py payload.json<\/code>. Exit code 0 means that the local checks passed; exit code 1 means rejection. The file contents are not printed.<\/p>\n
import json\nimport sys\nfrom decimal import Decimal, InvalidOperation\nfrom pathlib import Path\n\nMAX_BYTES = 1_048_576  # Local example policy, not a JSON limit.\n\ndef unique_object(pairs):\n    result = {}\n    for key, value in pairs:\n        if key in result:\n            raise ValueError("duplicate object member")\n        result[key] = value\n    return result\n\ndef reject_constant(value):\n    raise ValueError("non-JSON numeric constant")\n\ndef check(raw):\n    if len(raw) > MAX_BYTES:\n        raise ValueError("example size limit exceeded")\n    # Strict UTF-8; this example also rejects a leading BOM.\n    text = raw.decode("utf-8")\n    if text.startswith("\\ufeff"):\n        raise ValueError("leading BOM rejected by local policy")\n    value = json.loads(text, object_pairs_hook=unique_object,\n                       parse_float=Decimal, parse_constant=reject_constant)\n    # Reject lone UTF-16 surrogates for interoperable Unicode text.\n    def visit(x):\n        if isinstance(x, str):\n            x.encode("utf-8")\n        elif isinstance(x, dict):\n            for key, item in x.items():\n                visit(key)\n                visit(item)\n        elif isinstance(x, list):\n            for item in x:\n                visit(item)\n    visit(value)\n    return value\n\nif __name__ == "__main__":\n    if len(sys.argv) != 2:\n        raise SystemExit("Usage: python3 check_json.py payload.json")\n    try:\n        with Path(sys.argv[1]).open("rb") as stream:\n            raw = stream.read(MAX_BYTES + 1)\n        check(raw)\n    except json.JSONDecodeError as exc:\n        print(f"Syntax error: line {exc.lineno}, column {exc.colno}",\n              file=sys.stderr)\n        raise SystemExit(1)\n    except (OSError, ValueError, UnicodeError, RecursionError,\n            InvalidOperation, OverflowError):\n        print("Rejected: encoding, duplicate, value or resource policy",\n              file=sys.stderr)\n        raise SystemExit(1)\n    print("OK: JSON plus the example's interoperability checks")\n<\/code><\/pre>\n
The one-mebibyte limit, rejection of a leading BOM and rejection of lone surrogate characters are explicit interoperability\/resource policies. They are not a claim that every rejected input violates the JSON grammar. The parser also has implementation limits. This example is not a complete defense against hostile input.<\/p>\n
Python’s default decoder accepts NaN and Infinity as extensions; parse_constant<\/code> disables that behavior here. Decimal<\/code> preserves decimal input for checking, while integer input remains a Python integer. Neither choice proves that a later JavaScript consumer or external API can represent the same value.<\/p>\n
Diagnostics from the original evidence<\/h2>\n
Python exposes line and column for a syntax error. JavaScript error messages vary by engine and version; extracting an English \u201cposition\u201d phrase is not a portable API. Character offsets, UTF-16 code units and byte offsets must not be mixed. Tabs and line breaks also make a hand-built caret unreliable.<\/p>\n
Local inspection around the original location is useful. Production logs should avoid dumping full payloads containing personal data or credentials. A syntax diagnostic locates where parsing failed, which can be after the actual mistake.<\/p>\n
What jq does and does not establish<\/h2>\n
jq -e .<\/code> is not a pure validity test: valid false and null values produce a nonzero exit status. jq also normally reads a stream of JSON values, so acceptance does not by itself establish exactly one document. Empty input and extensions need explicit treatment. The Python checker above makes the intended policy clear.<\/p>\n
Numeric behavior depends on jq version and build options. Literal preservation and arithmetic conversion are separate matters; a blanket guarantee for every build since version 1.7 is incorrect. A pretty-printed copy should not replace the original evidence for precision analysis.<\/p>\n
The actual tag or API contract<\/h2>\n
A successful local check does not validate required fields, event names, currency, dates or business rules. The generated payload needs the receiving platform’s schema and documented diagnostic tools. Responses and processing results must also be observed; an HTTP status alone may not establish correct downstream data.<\/p>\n
For JSON-LD, validation applies to the rendered page and the relevant structured-data type. One broken block does not prove that every other block is unreadable. Correct syntax also does not guarantee rich results. For tag templates, import validation and runtime behavior are separate checks; the failure point depends on the actual format and platform.<\/p>\n
\n
Questions and answers<\/h2>\n
How does JSON.parse in the browser handle duplicate names?<\/h3>\n
It reports no error and keeps the last value. {\"a\":1,\"a\":2}<\/code> becomes an object with a = 2, and nothing in the result shows that there was a first value. A tag that reads the payload in the browser therefore never sees the duplicate, which is why checking the original text before parsing pays off.<\/p>\n
Which values does JSON.stringify change silently when generating a payload?<\/h3>\n
Several, and only one case raises an error. Code that assembles a payload in JavaScript, for example in a custom variable, can run into these cases:<\/p>\n