2026-09-25 · 6 min read · Rahul Chitturi
- json-schema
- validation
- debugging
JSON Schema format can describe familiar strings such as date-time, email, hostname, URI, and UUID. Depending on the dialect and validator configuration, a format keyword may collect an annotation without making an invalid-looking value fail validation.
Teams are surprised when an editor rejects a value that an API accepts, or when enabling assertions during a library upgrade turns previously accepted documents into errors.
Identify the effective semantics
Record the schema's $schema URI, declared vocabularies, validator name and version, format plugins, assertion options, and the exact format name. Check the applicable draft rather than assuming every implementation uses the same historical behavior.
- Separate format annotation from format assertion.
- Confirm that optional checker packages are installed.
- Treat unknown format names according to explicit policy.
- Keep business rules out of loosely defined custom formats.
Reduce the value to a boundary table
Build positive and negative fixtures around syntax, ranges, leap days, timezone offsets, Unicode, case, trailing whitespace, and implementation limits. For date-time values, distinguish standards conformance from application requirements such as UTC-only storage.
If systems disagree, compare pass or fail results before comparing diagnostic text. A regex approximation can also diverge from a standards-aware parser and should not silently replace one.
Verify without production data
Use Flashman's JSON formatter for schemas and fixtures, regex tester for public pattern experiments, timestamp converter for date boundaries, and diff tool for validator matrices.
Test annotation-only and assertion modes, unknown and custom formats, nested schemas, reference boundaries, malformed Unicode, locale differences, validator upgrades, generated clients, and every production language.