JSON data ⇔ JSON Schema compatibility verification/validator | ZeroTools

In system development using JSON, checking whether the placement of curly braces and quotation marks conforms to syntax specifications (syntax check) and verifying whether the data content matches structural definitions (Schema validation) are two entirely different processes.

Since text with syntax errors is rejected by JSON.parse before validation can begin, this tool requires both inputs to be parsed into in-memory structures.

During this conversion process, original textual details such as whitespace formatting and duplicate object keys are lost, retaining only the last value parsed.

Furthermore, when bidirectionally converting JSON data with CSV row structures, XML attributes, or TypeScript types, the unique semantic nuances of each format are easily lost.

The schema validation provided by this tool verifies whether the parsed JSON data satisfies the specified types, constraints, and required fields according to a bounded subset of JSON Schema Draft-07.

It does not possess the capability to restore lexical details lost during parsing, nor does it guarantee the validity of conversions between disparate data serialization formats.

Validating JSON data is an essential step toward increasing application reliability, but a successful validation alone cannot guarantee overall data quality or business correctness.

All parsed numeric values in this tool must be finite numbers, and integers must fall within JavaScript safe integer boundaries. Finite fractions and negative zero (-0) are permitted, with -0 treated as equivalent to 0 in evaluations.

These numerical boundaries represent practical tool input limitations rather than violations of the JSON Schema specification itself.

Because standard JSON.parse rounds excessively large or precise numbers to IEEE-754 double precision floats without error, lexical precision cannot be fully restored or guaranteed.

Data validation inside this tool is strictly isolated within the current browser session. A clean validation result confirms solely that the provided JSON document complies with the evaluated subset of schema rules under tool bounds.

It provides no guarantees regarding external application schemas, relational database integrity, API contract compatibility, or security posture.

Understanding these operational boundaries ensures that schema verification is positioned properly within a comprehensive testing and validation pipeline.

This tool provides a bounded verification engine limited to a specific subset of JSON Schema Draft-07 keywords. Supported keywords are type, required, properties, items, minItems, maxItems, minLength, maxLength, pattern, minimum, maximum, and enum.

Boolean schemas are supported: true accepts any instance value, while false unconditionally marks the instance invalid. A root schema must be either an object or a boolean; passing a null root schema or scalar schema results in a schema error, whereas instance data may be any valid JSON type including scalars and null.

Unlike standard Draft-07 processors that ignore unknown keywords by default, this tool enforces a strict fail-closed product policy.

Any unsupported or unrecognized keyword—including $ref, format, const, additionalProperties, definitions, and composite applicators like anyOf or oneOf—causes the validator to reject the schema and halt execution immediately.

No external reference resolution or remote URI network fetching is performed. Child schema definitions are inspected comprehensively ahead of validation, rejecting invalid definitions even if the corresponding data properties are absent in the instance.

Accepted metadata keywords include $schema, $id, title, description, default, and examples. The $schema keyword is permitted only at the schema root and must either be omitted or match the official Draft-07 URI (http://json-schema.org/draft-07/schema#, https://json-schema.org/draft-07/schema#, or their unhashed equivalents).

The $id keyword is accepted as a plain string, but the tool does not implement its standard identifier, base URI resolution, or dereferencing semantics.

Annotation fields like title, description, and examples are stored without side effects, and default values are never applied or injected into instance documents.

The type keyword accepts either a single type name or an array of unique type names chosen from seven standard types: "null", "boolean", "object", "array", "number", "string", and "integer".

In this system, "number" includes integers (such as 1.0), and an array such as ["integer", "number"] is valid because it consists of distinct strings, even though their numeric domains overlap.

The required keyword requires an array of unique strings, though an empty array is permissible. By strictly inspecting definition validity up front, this tool avoids ambiguous validation states.

JSON data frequently organizes complex hierarchies by nesting objects and arrays. This tool traverses schema definitions defined in properties and items to recursively validate data structures depth-first.

For object schemas, data properties are optional unless specified in required, and undeclared additional properties are not forbidden.

Validation checks only the target data object's own properties, meaning special keys like __proto__ or constructor are treated as data only if they are present as own properties on the instance, while inherited prototype properties are not considered present.

Array validation requires items to be a single schema object or boolean; tuple-based array schemas are unsupported and blocked as definition errors.

The keywords minItems and maxItems operate as independent constraints on array length, functioning regardless of whether items is defined.

When items is present, every element in the array is sequentially checked against the child schema. If contradictory bounds are specified, such as minItems greater than maxItems, the schema remains structurally valid under the specification but becomes unsatisfiable by any instance.

To safeguard browser responsiveness and prevent stack overflows from deeply nested or cyclic structures, execution limits are strictly enforced during traversal.

The validator caps hierarchical tree depth at 64 (with root depth 1) and limits the total number of visited nodes to 20,000 per document across both schema and instance.

Furthermore, total evaluation operations are constrained by an overarching step counter capped at 100,000 global steps. Reaching any of these structural bounds halts processing immediately.

Because additional undeclared properties are not forbidden and complex composition keywords are blocked, passing validation confirms only that explicitly declared constraints were satisfied during limited inspection of the current data.

It does not certify all-validity, exact structural compliance, absence of extraneous data, or that unchecked nested fields meet unstated business criteria.

Recursive inspection performs a bounded evaluation against the supported keyword subset rather than providing an exhaustive architectural certification.

Evaluation of scalar constraints relies on precise computational rules designed for predictable execution. The string boundary keywords minLength and maxLength calculate string length using Unicode code points rather than UTF-16 code units or visual grapheme clusters.

Consequently, characters encoded via surrogate pairs count as single code points, aligning string length evaluation with JSON Schema specifications while differentiating it from raw JavaScript .length measurements.

Regular expression validation via the pattern keyword constructs a regular expression instance using the unicode flag (new RegExp(pattern, "u")).

The regex tests for substring matches without implicit start or end anchors. Syntactically invalid regular expressions and patterns exceeding 5,000 UTF-16 code units are detected and halted during schema inspection, before instance data is tested and even if the property is absent from the instance.

Users should note that regex dialect features and performance may exhibit subtle variances across different browser engines.

Numeric boundaries specified by minimum and maximum are inclusive comparisons evaluated using standard floating-point arithmetic.

Safe integer values and finite decimal numbers are compared directly against the specified thresholds. While conflicting constraints (such as a minimum greater than maximum) are accepted as valid schema definitions, no numeric instance can satisfy them.

Because numbers are parsed via standard JSON deserialization, edge cases involving extreme precision or floating-point rounding inherit the host JavaScript runtime's numeric characteristics.

The enum keyword requires a non-empty array of items that are structurally unique, enforced as a strict product policy. When checking instances against enum values, equality comparison ignores key ordering in objects, preserves element ordering in arrays, and treats 0 and -0 as well as 1 and 1.0 as identical values.

Deep structural equality is performed for nested structures up to the global step limit, ensuring reliable set membership testing without relying on fragile reference equality.

When structural mismatches, definition flaws, or runtime interruptions occur, the validator produces structured issue reports to identify the exact source of failure.

Issue records categorize findings into three distinct origins: schema for definition errors, instance for data validation failures, and runtime for budget or environment terminations.

This clear distinction prevents confusion between ill-formed schema documents, non-conforming JSON payloads, and execution halts.

Problem locations are pinpointed using standard RFC 6901 JSON Pointer paths rather than ambiguous dot-and-bracket notation. The root of a document is represented by an empty string, while hierarchical levels are separated by forward slashes, escaping special characters such as ~ to ~0 and / to ~1.

For example, a validation mismatch on the price property of the third item in an array is reported precisely as /items/2/price.

This standardized notation allows automated tools and developers to locate problematic fields unambiguously.

To avoid uncontrolled payload growth, the validator enforces a maximum limit of 100 reported issues and a cumulative text budget of 200,000 UTF-16 code units across issue paths, argument strings, and issue codes (rather than a JSON-serialized byte cap).

If an evaluation encounters a 101st issue or exceeds this 200,000 UTF-16 character limit, all previously collected partial issues are discarded and replaced solely by a single limit notice.

Exactly 100 issues can complete with an invalid status, and these resource budgets serve as defensive upper bounds rather than a hard guarantee against memory exhaustion.

The user interface separates schema definition errors, invalid JSON input syntax, constraint violations, execution blocks, and user-initiated cancellations into dedicated alert categories.

Modifying any editor input, choosing a preset, clearing fields, or navigating away automatically cancels pending tasks and discards obsolete results.

This design prevents stale success indicators from lingering on the screen when underlying inputs are edited.

To keep the main interface responsive and prevent long-running tasks from locking the browser thread, validation execution runs inside a dedicated Web Worker.

When validation is triggered, the main thread performs an initial length check ensuring neither schema nor instance text exceeds 100,000 UTF-16 code units.

If inputs pass this check, the Worker initiates JSON parsing, schema definition inspection, regular expression compilation, and recursive data verification.

Execution is constrained by operational bounds, including a maximum 1,000-millisecond waiting deadline measured from Worker startup and message transfer, which does not constitute a hard one-second CPU execution or OS-level timer guarantee and can be delayed by background scheduling or blocked host processes.

If the Worker times out, becomes unavailable, or throws an unhandled error, the system records a blocked status with no synchronous fallback execution on the main thread.

When users trigger the Stop control, the interface requests Worker termination without recording a false validation pass.

This lightweight tool focuses on rapid local verification of basic structural constraints. It does not replace full-featured specification engines when projects require enterprise features such as dynamic schema loading via $ref, semantic format assertions (format), or schema synthesis through composition keywords.

When such advanced constraints or cross-file dependencies are required, teams should incorporate comprehensive JSON Schema validation libraries into their automated build and test pipelines.

While the validator tool does not explicitly transmit conversion payloads to external servers, the hosting site loads separate assets, analytics, and advertising scripts that may technically access the DOM, so no claim is made that third-party scripts never access or inspect input data.

This client-side execution does not constitute an end-to-end security certification, and users should exercise caution regarding local browser extensions, device compromises, and the handling of confidential information.

Input character limits and worker budgets cannot guarantee complete privacy or protect against all operational risks.