Make the model return valid JSON, and use JSON Schema to constrain the output structure precisely
When performing information extraction or structured data generation, a model may return extra text (such as a
JSON Object mode ensures the output is a valid JSON string, but does not guarantee a specific structure. To use it:
Qwen3.8-Max series, Qwen3.7-Max series, and Qwen3.7-Plus series. More models are coming soon.
This example extracts structured information from a personal profile using JSON Object mode.
SDK response:
Multimodal models support structured output for images and video. Use JSON mode to pull structured data out of visual content, such as field values from receipts, object locations in images, or events in video.
The following example extracts ticket and invoice fields from a scanned receipt.
Response:
Ambiguous prompts like "return user information" lead to unpredictable output structures. For reliable results, describe the expected schema in your prompt: specify field names, types, required vs. optional status, format constraints (such as date format), and include examples.
The system prompt below does all of this. It constrains field types, distinguishes required from optional fields, and uses four examples to show that the
Pass it as the system message:
Response:
JSON Object mode only guarantees that the output is valid JSON — field names, types, and nesting may still differ from what you expect. For automated parsing, API interoperability, and other cases that need strict type constraints, set
This example forces the model to output a JSON object with the required fields
The OpenAI SDK's
Response:
Validate before passing downstream
In JSON Object mode the output is guaranteed to be valid JSON, but not to match your business schema. Validate it with a library such as jsonschema (Python), Ajv (JavaScript), or Everit (Java) before handing it to downstream services, so missing fields or type errors don't cause parsing failures, data loss, or broken business logic. On failure, retry the request or have a model rewrite the output.
Do not set max_tokens
Leave
If a call fails and returns an error message, see Error messages for resolution.
```json wrapper) that breaks downstream parsing. Enabling structured output ensures the model returns a valid JSON string. JSON Schema mode goes further and gives you precise control over the output structure and types, eliminating extra validation or retries.
Two modes
| Feature | JSON Object mode | JSON Schema mode |
|---|---|---|
| Outputs valid JSON | Yes | Yes |
| Strictly follows schema | No | Yes |
| Supported models | Most Qwen models, Kimi, GLM, DeepSeek | Selected models only |
response_format setting | {"type": "json_object"} | {"type": "json_schema", "json_schema": {...}, "strict": true} |
| Prompt requirement | Must include "JSON" | Recommended to describe explicitly |
| Use case | Flexible JSON output | Precise schema validation |
- Set
response_formatin the request body to{"type": "json_object"}. - Include the word "JSON" (case-insensitive) in the system message or user message. Otherwise the API returns:
'messages' must contain the word 'json' in some form, to use 'response_format' of type 'json_object'.
response_format to {"type": "json_schema", "json_schema": {...}, "strict": true}.
JSON Schema mode does not require the "JSON" keyword in the prompt.
Supported models
JSON Object
View the full model list
View the full model list
Qwen
Text generation models- Qwen-Max: Qwen3.8-Max series, Qwen3.7-Max series
- Qwen-Max (non-thinking mode): Qwen3.6-Max series, Qwen3-Max series, Qwen-Max series
- Qwen-Plus: Qwen3.7-Plus series
- Qwen-Plus (non-thinking mode): Qwen3.6-Plus series, Qwen3.5-Plus series, Qwen-Plus series
- Qwen-Flash: Qwen3.7-Flash series
- Qwen-Flash (non-thinking mode): Qwen3.6-Flash series, Qwen3.5-Flash series, Qwen-Flash series
- Qwen-Turbo (non-thinking mode): Qwen-Turbo series
- Qwen-Coder: Qwen3-Coder series
- Qwen-Long: Qwen-Long series
- Qwen3.8 open-source series
- Open-source series (non-thinking mode): Qwen3.6 open-source series, Qwen3.5 open-source series, Qwen3 open-source series
- Open-source series: Qwen3.8 open-source series (
qwen3.8-2.4t-a95b), Qwen3-Coder open-source series, Qwen2.5 open-source series (excluding math and coder models)
- Qwen-VL: Qwen3-VL-Plus series, Qwen3-VL-Flash series, Qwen-VL-Max series (excluding latest and snapshot versions), Qwen-VL-Plus series (excluding latest and snapshot versions)
- Qwen-Omni: Qwen3.5-Omni-Plus series
- Open-source series: Qwen3-VL open-source series
Kimi
kimi-k2-thinking
GLM
glm-5.1- Non-thinking mode:
glm-5,glm-4.7,glm-4.6
DeepSeek
deepseek-v4-pro-0813,deepseek-v4-pro,deepseek-v4-flash
Models labeled "non-thinking mode" accept
response_format set to {"type": "json_object"} in thinking mode without error, but structured output may not take effect. To reliably get valid JSON from these models in thinking mode, see the FAQ.JSON Schema
Qwen3.8-Max series, Qwen3.7-Max series, and Qwen3.7-Plus series. More models are coming soon.
Getting started
This example extracts structured information from a personal profile using JSON Object mode.
Before calling, obtain an API key and export it as an environment variable. To call through the OpenAI SDK or DashScope SDK, install the SDK first.
- OpenAI compatible
- DashScope
Full curl response
Full curl response
Extract structured data from images and video
Multimodal models support structured output for images and video. Use JSON mode to pull structured data out of visual content, such as field values from receipts, object locations in images, or events in video.
The following example extracts ticket and invoice fields from a scanned receipt.
For image and video file limits, see Image and video understanding.
- OpenAI compatible
- DashScope
Optimize prompts
Ambiguous prompts like "return user information" lead to unpredictable output structures. For reliable results, describe the expected schema in your prompt: specify field names, types, required vs. optional status, format constraints (such as date format), and include examples.
The system prompt below does all of this. It constrains field types, distinguishes required from optional fields, and uses four examples to show that the hobby field is omitted entirely when hobbies are not mentioned.
System prompt
- OpenAI compatible
- DashScope
Constrain output precisely with JSON Schema
JSON Object mode only guarantees that the output is valid JSON — field names, types, and nesting may still differ from what you expect. For automated parsing, API interoperability, and other cases that need strict type constraints, set type to json_schema. The model then follows the schema exactly.
The response_format structure looks like this:
name and age, plus the optional field email.
How to use
The OpenAI SDK's parse method accepts a Python Pydantic class or a Node.js Zod object directly and converts it to a JSON Schema for you, so you never write the schema by hand. With the DashScope SDK, construct the JSON Schema manually using the format above.
- OpenAI compatible
- DashScope
Configuration guide
Declaring required fields
Declaring required fields
List required fields in the If the input does not provide email information, the output omits the field.
required array and leave optional fields out:Implementing optional fields
Implementing optional fields
Besides leaving a field out of The output then always includes the
required, you can allow the null type:email field, but its value may be null.additionalProperties configuration
additionalProperties configuration
Controls whether the model may output fields not defined in the schema:For the input "I'm Zhang San, 25 years old", the output is
{"name": "Zhang San", "age": 25} — including the undefined age field.| Value | Behavior | Use case |
|---|---|---|
false | Only output defined fields | Precise structure control |
true | Allow extra fields | Capture more information |
Supported data types
Supported data types
string, number, integer, boolean, object, array, enum.Going live
Validate before passing downstream
In JSON Object mode the output is guaranteed to be valid JSON, but not to match your business schema. Validate it with a library such as jsonschema (Python), Ajv (JavaScript), or Everit (Java) before handing it to downstream services, so missing fields or type errors don't cause parsing failures, data loss, or broken business logic. On failure, retry the request or have a model rewrite the output.
Do not set max_tokens
Leave max_tokens unset when structured output is enabled. This parameter caps the number of output tokens (the default is the model's maximum) and can truncate the JSON string mid-output, producing invalid JSON.
Use the SDK to generate schemas
Let the SDK generate the schema. This avoids errors from hand-maintained schemas and gives you automatic validation plus a type-safe parsed result.
FAQ
How do I get structured output from a model labeled “non-thinking mode” when thinking is enabled?
How do I get structured output from a model labeled “non-thinking mode” when thinking is enabled?
Models labeled "non-thinking mode" in Supported models may return content that is not strictly valid JSON when thinking mode is on. Use a two-step approach: first call the thinking model to get high-quality output, then pass any malformed JSON through a model that supports JSON Object mode to fix it.Step 1: Get the output from thinking modeStep 2: Validate and repair the outputTry to parse the
Setting
response_format to {"type": "json_object"} with thinking mode enabled does not cause an error. The example below is a fallback that intentionally omits response_format; use it only to demonstrate the two-step repair when a model's output is not valid JSON.json_string from the previous step. If it is valid JSON, use it directly. If not, call a model that supports structured output to repair it — pick a fast, low-cost model such as qwen-flash in non-thinking mode.