✅ JSON Result Validator
Stop trusting VLM JSON with your life — check it instead
- valid
- normalized_json
- error
Vision models are getting better at JSON output, but "better" is doing a lot of work. Every structured-output workflow eventually hits the model that wraps its JSON in a Markdown code block, omits a field it was told was mandatory, or returns prose when you asked for a parseable object. JSON Result Validator is the pack's reality check: it takes whatever text your VLM produced, tries to parse it as JSON, and tells you exactly what's wrong.
It's a pure validation node - no model, no network. You feed it the results_json or result output of a VLM task and a list of required top-level fields, and it returns three things: a valid BOOLEAN, a pretty-printed normalized_json STRING, and an error STRING. That BOOLEAN is the useful part: wire it into a conditional/switch node and you can automatically retry, fall back to a different model, or route the batch row to a human-review pile when the VLM mangles its output.
The two inputs
- json_text - the raw VLM output. Comes straight off Remote VLM Business Task's
results_json, or a JSON task's output. - required_fields - a comma-separated list of top-level keys you expect, e.g.
subject,tags. The validator checks that each one exists at the top level of the parsed object.
Under the hood (utils/json_schema_tools.py) it parses with the standard json library, collects any missing fields, and reports them. Invalid JSON gives you a clear "Invalid JSON: …" error; missing keys give "Missing fields: subject". Normalized JSON comes back indented, so you can eyeball it in a text node or pipe it downstream cleanly.
Where this earns its keep
In a batch workflow, one malformed row can poison the whole run - especially if you're feeding VLM output into another step that assumes valid JSON. This validator lets you detect rather than discover. Batch Remote VLM Task already per-item isolates failures, but it can't tell you the JSON is semantically wrong, only that a request failed. This node catches the "valid request, garbage structure" case.
The honest limitation: it checks top-level field presence, not types or values. A model that emits "tags": "oops not an array" passes if tags exists. If you need strict schema validation, you'll want a dedicated JSON tool downstream - this node is the cheap gate, not the full inspection.
Install
Same as every node in this pack:
cd ComfyUI/custom_nodes
git clone https://github.com/walke2019/ComfyUI-GGUF-VLM.git
cd ComfyUI-GGUF-VLM
pip install -r requirements.txt
Restart ComfyUI. It's under GGUF-VLM → 🚀 Business. No model downloads needed for this one.
Troubleshooting
The most common confusion is feeding it the wrong thing: the VLM's task runners output pretty-printed JSON from a "JSON" task, but if you chose "Custom" and your prompt didn't actually demand JSON, you'll feed it prose and get a perpetual valid: false. That's the validator doing its job - your prompt is the problem, not the node. And remember the builder nodes exist: the JSON prompt template in this pack explicitly forbids Markdown code blocks, which is the single most common way VLM "JSON" comes back unparseable.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| json_text | STRING | {} | — |
| required_fields | STRING | subject,tags | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| valid | BOOLEAN | — |
| normalized_json | STRING | — |
| error | STRING | — |