How to Prompt Mistral for Structured Output & JSON (2026)

If you want Mistral to return data your code can parse — not a paragraph about the data — you have to specify the shape, forbid everything else, and plan for the edge cases. This guide gives you the formula, the exact wording that stops Mistral wrapping JSON in prose, and 10 full prompts for extraction, classification, and tool use. Structured output and function calling are two of Mistral's real strengths, so the payoff is high. For finished prompts once the pattern clicks, keep the best Mistral prompts open in another tab.

Why Mistral is good at this

Mistral's sweet spot in 2026 is efficient, reliable, structured work. The models are tuned for native function calling and structured output, which is exactly why teams reach for them in extraction pipelines and classification jobs at a lower cost than some US frontier models.

• Schema-following. Give Mistral exact keys and types and it sticks to them closely, which is the whole game for anything downstream code will read.
• JSON mode via the API. Beyond prompting, the Mistral API supports a JSON response format and schema enforcement, so the output is constrained to parse — not just asked to.
• Long context. Mistral Medium 3.5's 256K-token window means you can extract from a whole document in one call instead of chunking.
• Efficiency. Structured tasks are often high-volume; Mistral's lower cost per token makes it practical to run at scale.

The takeaway: Le Chat is fine for one-off structured tasks, but if you are wiring Mistral into a product, do the prompting and turn on JSON mode. The prompt gets you the right shape; the API setting guarantees it parses.

The structured-output formula

Every reliable structured-output prompt has four parts: [Role/Task] + [Exact schema] + [Output rule] + [Fallback]. The role says what to do, the schema defines the shape down to the types, the output rule forbids anything that is not the data, and the fallback tells Mistral what to return when the input is empty or unparseable.

Written as one prompt, it reads like this:

You are an extraction function. Extract the details from the text into valid JSON only — no prose, no markdown fences. Use exactly this schema: {"name": string, "email": string, "company": string, "intent": one of ["demo","pricing","support","other"]}. If a field is missing, use null. Do not invent values. If the text is empty, return {}. Text: [PASTE TEXT]

Best for: any task where a program, not a person, reads Mistral's answer.

Naming the schema

The schema is the highest-leverage part. Vague requests get vague shapes; a precise schema gets a precise object. A few rules make the difference:

• Name every key and its type. Write "price": number, not "include the price." Types stop Mistral returning "€12" where you wanted 12.
• Constrain enums explicitly. "status": one of ["open","closed","pending"] prevents free-text categories that break your switch statement.
• Nest and array where the data does. Model real structure: "items": [{"sku": string, "qty": number}]. Define the single item, then ask for the array.
• Show a one-line example. A single example of the exact expected output removes almost all ambiguity about formatting.
• Say what is optional. Mark optional fields and give the missing-value rule so Mistral does not fabricate to fill the shape.

When precision matters most — production pipelines — pair this with the API's schema enforcement so the model literally cannot return a shape that fails to parse. In Le Chat, the prompt alone is usually enough.

Constraints & fallbacks

Structured output fails in predictable ways: extra prose, markdown fences, invented values, and choking on empty input. Each has a one-line fix you should include by default.

• Forbid the wrapper. "Output the JSON object only. No text before or after, and no code fence." This kills the "Here is your JSON:" preamble.
• Ban invention. "Do not infer or invent values. If it is not in the source, use null." Extraction should never hallucinate a field.
• Define empty and invalid input. "If the input is empty or unreadable, return {\"error\": \"invalid input\"}." Now your parser always gets valid JSON.
• Preserve exact values. For numbers, dates, and IDs, "copy exactly, do not reformat" prevents silent changes to 0012 or a date format.
• Ask for the array on lists. "Return a JSON array; if there are no items, return []." Consistent shape means one code path, not two.

A prompt that names the schema, forbids the wrapper, bans invention, and defines the empty case is dramatically more robust than "give me the data as JSON." When you need this discipline across a real codebase, the Mistral coding prompts extend it to functions and tests.

10 example prompts

Each prompt below uses the formula: task, exact schema, output rule, and a fallback. Copy any of them, swap the [bracketed placeholders], and run.

1. Extract contact details

You are an extraction function. From the text, return valid JSON only — no prose, no fences — using exactly: {"name": string, "email": string, "phone": string, "company": string, "role": string}. Use null for any missing field, and do not invent values. If the text is empty, return {}. Text: [PASTE TEXT]

Best for: Turning signatures, bios, or form submissions into clean contact records.

2. Classify support tickets

You are a classifier. For each input, return valid JSON only matching: {"category": one of ["billing","technical","account","feedback","other"], "priority": one of ["low","medium","high","urgent"], "summary": string (max 15 words)}. No prose, no markdown fences. If the input is empty, return {"category":"other","priority":"low","summary":"empty input"}. Inputs: [PASTE ITEMS]

Best for: Routing and triage; the fixed enums keep the output safe to switch on.

3. Extract a list of items

Extract every line item from the invoice text into a JSON array. Each element must match: {"description": string, "qty": number, "unit_price": number, "total": number}. Return the array only — no prose, no fences. Copy numbers exactly, do not recalculate. If there are no line items, return []. Text: [PASTE INVOICE TEXT]

Best for: Line-item extraction where the array shape must stay consistent for your parser.

4. Structured document summary

Summarize the attached document into valid JSON only, using: {"title": string, "one_line_summary": string, "key_points": [string], "entities": {"people": [string], "orgs": [string], "dates": [string]}, "action_items": [string]}. No prose outside the JSON. Use empty arrays where nothing applies, and do not invent entities. Return the object only.

Best for: Feeding a summary into an app or database instead of reading it yourself.

5. Sentiment and aspects

Analyze each review and return a JSON array where each element is: {"sentiment": one of ["positive","neutral","negative"], "score": number between -1 and 1, "aspects": [{"aspect": string, "sentiment": one of ["positive","neutral","negative"]}]}. JSON only, no fences. If a review is empty, use {"sentiment":"neutral","score":0,"aspects":[]}. Reviews: [PASTE REVIEWS]

Best for: Aspect-based sentiment on product reviews or survey responses.

6. Normalize messy data

Normalize each row into valid JSON matching: {"full_name": string, "email_lowercase": string, "country_iso2": string, "signup_date_iso": string in YYYY-MM-DD}. Standardize casing, trim whitespace, convert country names to ISO-2 codes, and reformat dates to ISO. If a value cannot be normalized confidently, set it to null and add it to a top-level "flags" array. Return one JSON object per row. Rows: [PASTE ROWS]

Best for: Cleaning imported data with a clear audit trail of what could not be normalized.

7. Define a tool/function call

You can call one function: search_flights(origin: string IATA, destination: string IATA, date: string YYYY-MM-DD, passengers: number). Given the user request, return valid JSON only with the arguments to call it: {"function": "search_flights", "arguments": {…}}. If the request is missing a required argument, instead return {"clarify": string} asking for exactly what is missing. Request: [PASTE REQUEST]

Best for: Prototyping tool use and function calling before wiring it to a real API.

8. Extract a table to JSON

Read the attached [scanned table / spreadsheet], run OCR if needed, and convert it to a JSON array of row objects using these column keys exactly: [KEY1, KEY2, KEY3]. Preserve exact values and do not reformat numbers or dates. Mark any cell you could not read as null and list the affected rows in a top-level "unreadable_rows" array. Return the object only.

Best for: Digitizing tables from PDFs or images with a record of low-confidence cells.

9. Generate test data

Generate [10] realistic but fake records as a JSON array. Each element must match: {"id": number, "name": string, "email": string, "plan": one of ["free","pro","enterprise"], "created_at": string YYYY-MM-DD, "active": boolean}. Make the data varied and plausible, use obviously fake emails (example.com), and return the array only — no prose, no fences.

Best for: Seeding a database or a demo with structured, safe sample data.

10. Convert prose to a config

Convert this plain-English description into valid JSON config matching exactly: {"name": string, "schedule": {"cron": string}, "retries": number, "notify": [string], "enabled": boolean}. Interpret times and frequencies into a standard cron expression, and if anything is ambiguous, choose a sensible default and note it in a top-level "assumptions" array. Return the object only. Description: [PASTE DESCRIPTION]

Best for: Turning a request in words into a machine-readable config, with assumptions surfaced. For reusable versions, see the Mistral prompt templates.