Structured Output: JSON vs Markdown vs Tables (Prompt Guide)

A freight brokerage processes more than 400 carrier invoices a day. Clerks paste each invoice’s text into ChatGPT, ask for the line items, and get back a tidy paragraph they still have to retype into the billing system. The extraction is right; the shape is wrong. The real question is never “can the model read an invoice” but “which output format drops straight into the next step without a human reformatting it.”

This guide makes that choice explicit. We compare three output formats — JSON, Markdown, and a flat table — and give a decision rule, an exact prompt snippet, and the trade-off for each. Every example uses the same job: pulling line items (description, weight, rate, charge) out of a freight invoice. If you are wiring extraction into a scheduled job, keep the format rule in your system prompt templates instead of retyping it per request. For settings that keep repeated extractions stable, see research summary prompt settings.

Output Format Decision Table

Treat the table as a first filter, not the whole decision. Ask two questions: who consumes the output (a program or a person), and how regular the data is (fixed fields or freeform text). Program plus fixed fields means JSON. Person plus freeform means Markdown. Person plus many parallel rows means a flat table. Most invoice automation fails because the builder answers only the first question and ignores the second.

When to Use Each Format

JSON when a program is the consumer. If the next step is code — inserting rows, matching against a purchase order, triggering a payment — JSON is the only format that survives a parser. Field names become a contract: description, weight_kg, rate, charge. The model should not rename them mid-run, and your script can fail loudly when one is missing. Reach for JSON whenever the same prompt will run in a loop over hundreds of documents.

Markdown when a person is the consumer. For an approval queue, a dispute email, or an exception report, Markdown wins because it is readable without a renderer. Headings, bold labels, and short bullets let a clerk scan twenty invoices in a minute. Markdown is also forgiving: if an invoice never states a rate, the model can write “rate not stated” inline without breaking a schema.

A flat table when the value is in comparison. When the same fields repeat across many invoices or many line items, a grid shows totals, outliers, and gaps at once. Tables are ideal for a spot check (“does line 4’s weight look wrong?”) and for pasting into a spreadsheet. They break the moment records nest, because a line item with its own sub-charges has nowhere to sit in a flat grid.

Prompt Snippets by Format

JSON extraction

Extract every line item from the freight invoice below. Return ONLY valid JSON, no prose, no code fences.
Schema:
{
  "invoice_number": "string",
  "carrier": "string",
  "line_items": [
    { "description": "string", "weight_kg": number, "rate": number, "charge": number }
  ],
  "total_charge": number
}
Rules:
- Use null for any field the invoice does not state.
- Keep numbers as numbers, never as strings.
- Do not invent line items and do not round values.
- If the text is unreadable, return {"error": "reason"}.
Invoice text:
[PASTE INVOICE TEXT]

Markdown brief

Turn the freight invoice below into a short Markdown brief for a billing clerk.
Structure:
- A one-line header with invoice number, carrier, and date.
- A bullet list of line items, each with a bold description and its charge.
- A bold "Total" line.
- A short "Flags" list for anything unclear, such as a missing rate or a weight that does not match the manifest.
Rules:
- Plain language, no jargon.
- Keep the whole brief under 150 words.
- Mark any value you had to guess as "unconfirmed".
Invoice text:
[PASTE INVOICE TEXT]

Flat HTML table

Extract the line items from the freight invoice below into one HTML table with exactly these columns: Description, Weight (kg), Rate, Charge.
Rules:
- One row per line item, in invoice order.
- No merged cells and no nested lists.
- Show an unknown value as a single dash.
- Add a final row labeled Total with the summed charge.
- Return the table only, with no explanation.
Invoice text:
[PASTE INVOICE TEXT]

Notice the pattern: the format instruction comes before the data, and the rule list comes before the format. Models weight the last thing they read, so restate the schema every call rather than trusting memory across a long conversation.

Trade-Offs and Failure Modes

JSON is strict but brittle. One stray comma breaks a parse, and a chatty model that prepends “Here is your JSON:” will still crash a strict decoder. Counter it by demanding “return only valid JSON” and by wrapping the call in a retry that strips any leading text. Tables are easy to read but easy to corrupt: a description that contains a line break can split one row into two, so ask for a dash instead of an empty cell. Markdown is the most forgiving and the least machine-friendly; never parse it with regular expressions when you could ask for JSON in the first place.

There is a cost angle too. JSON output is usually the longest, because of field names and brackets, and the longest output burns the most tokens. Markdown sits in the middle. A table is compact until descriptions run long. If you process thousands of invoices a day, measure tokens once per format and pick on cost, not on habit.

The safest production pattern is a two-pass design. Pass one asks for JSON because a program consumes it. Pass two, run only when a person needs to review, renders that JSON back into a table or a Markdown brief. The schema stays stable for code, the presentation stays friendly for people, and the two never have to agree on one format. Fix the format in the prompt, state it before the data, and repeat the schema on every call — consistency, not cleverness, is what makes structured output reliable.

Sources & Notes

Prompts tested with ChatGPT on the GPT-4o and GPT-4.1 models, plus Claude and Gemini, in October 2026. JSON behavior follows each vendor’s structured-output documentation; Markdown renders per CommonMark. The freight invoice fields (description, weight, rate, charge) are illustrative and not tied to any real carrier. No live parsing services were called; every prompt is copy-paste text for the reader to test in their own account. Category mapping follows the guunn.com AI Prompts plan (ChatGPT = 961).